►
From YouTube: CNCF CNF WG Meeting - 2021-01-11
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
Okay,
okay,
I
think
we
can
probably
get
started
there's
quite
a
few
people
on
the
call
and
people
are
joining
light
can
just
catch
up
afterwards.
So
thanks
everyone
for
joining.
This
is
the
cnf
working
group.
In
case
you
got
lost
and
stumbled
into
the
wrong
conference
room.
We
meet
weekly
mondays
at
1600
utc,
and
this
is
our
first
meeting
for
this
year.
A
So
before
we
jump
into
the
agenda
items,
is
there
anything
that
anyone
wants
to
add
or
likes
to
would
like
to
see
before
we
get
started.
A
I
do
see
that
anonymous
wombat
is
adding
chaos
experiments.
A
A
Sure,
and
if
nothing
as
I,
if
nobody
has
anything
else
to
add,
I
guess
we
can
jump
right
into
the
agenda,
then
so
first
on
the
agenda
is
voc.
I
think
he's
on
the
call
right.
A
Yes,
I'm
there
in
prison,
okay.
So
your
discussion
item
was
about
this
discussion
that
you
started
about
cnf
candidates
for
assessment.
Would
you
like
to
like
kick
it
off?
Do
you
want
me
to
open
it
for
you?
Would
you
like
to
share
your
screen.
C
No,
actually,
I
didn't
didn't
make
much
out
of
that.
I
wanted
originally
to
initiate
the
discussion,
as
we
are
putting
us
in
position
to
make
some
best
practices
and
then
some
some
rules
for
for
evaluation
of
the
cloud
native
network
functions.
C
I
thought
some
of
the
the
developers
of
the
network
functions
might
candidate
their
own
projects
to
actually
also
interact,
or
not
only
to
define
the
best
practices
and
the
the
requirements,
but
also
to
to
do
that
by
having,
in
inside
a
couple
of
I'm
not
saying
like
long
list
of
the
application,
but
a
couple
of
very
concrete
ones
that
we
can
use
as
a
basis
for
for
sparring
on
on
these
best
practices.
C
So
really
to
do
the
concrete
evaluations
of
the
of
the
concrete
functions
as
we
develop
best
practices,
and
then
it
would
serve
us
potentially
to
fine-tune
to
choose
if
some
best
practice
is
really
relevant
and
meaningful,
and
some
practices
are
not
in
that
sense.
So
just
to
have
a
little
bit
concrete.
C
Basis
for
discussion,
because
I
I
felt
so
far-
we
have
been
fairly
on
a
high
level
and
then
I
thought
it
might
be
good
to
if
somebody
of
the
developers
would
candidate
their
network
functions
with
a
which
they
consider
maybe
very
much
cloud
native
or
even
some
that
are
having
some
issues
with
that,
so
that
we
can
run
them
through
the
best
practices.
C
A
Yeah,
absolutely
thanks.
So
is
there
any
one
who's
either
a
scenic
vendor
developer
that
would
like
to
volunteer
one
of
their
cnfs
that
we
can
actually
have
some
kind
of
like
world
real
world
assessment
about
this
or
know
some.
It
also
doesn't
have
to
be
immediately.
You
can
also
say
I
want
to
take
time
and
reach
out
to
some
people.
I
know
see
if
they'd
be
interested.
C
D
Hello,
this
is
victor
morales.
I
just
have
a
question
regarding
this,
so
the
idea
that
you
have
is
basically
to
list
or
to
reference
the
the
cnf
from
here
to
the
projects
or
because
what
I
have
seen
is
like,
at
least
in
the
cnf
testbest
project.
There
is
a
couple
of
examples
where
we
can,
you
know,
use
it
or
yeah.
I
think
taylor
put
some
information
there.
D
Or,
but
for
now
is,
is
that
what
you
have
in
mind
like
these
two
reference,
those
cnf
from
the
repository.
C
I
don't
know
that
repository,
maybe
I'm
just
looking
now:
okay.
D
C
C
What
I
see
on
the
layer,
maybe
I
just
take
a
review.
If
you
can
put
the
link,
maybe
that's
what
I
meant.
C
I
was
more
on
not
more,
but
I
was
in
general,
looking
towards
having
a
well-defined
and
let's
say,
packaged
productized
cnf
that
somebody
of
the
developers,
vendors,
open
source
project,
has
and
then
use
it
as
a
as
a
real
life
check
for
the
for
the
assessment,
so
essentially
trying
to
do
assessments
according
to
the
the
best
practices
we
generate
like
there
is
one
that
was
sent
about
the
operator
view
platform
view
the
assessment
sheet.
D
C
Think,
maybe
maybe
some
of
just
to
add
to
that-
maybe
some
of
say
more
challenging
functions,
for
example,
taking
a
5g
core
data,
plane,
intensive
function
or
or
something
like
that
to
use
to
provide
the
the
borderline
case,
because
these
are
from
the
practice
appearing
as
the
most
problematic
or
not
problematic.
But
most
challenging
wants
to
fit
into
the
let's
say
normal
standard
kubernetes
model.
E
I
think
that
there's
also,
we
would
probably
want
to
go
over
more
than
one
in
this
like
we
want
to
start
with
one,
but
there's
there's
different,
there's
different
models,
there's
different
types
of
of
common
threads
that
we're
gonna,
see
here
that
that
we
may
want
to
investigate
and
check
against
that
particular
pattern.
So,
for
example,
you
may
have
one
that
is
very
heavy
around
around
how
how
how
apache
core
may
work
and
and
that
those
have
certain
assumptions
and
certain
control
plane
assumptions
that
are
that
are
made.
E
Then
you
may
have
others
that
are
that
are
completely
separate,
but
don't
don't
have
the
same
level
of
requirements
on
on
the
control
plane
that
freezes
up
to
to
had.
E
How
do
we
build
and
manage
it
without
having
to
bring
in
all
of
the,
and
I
don't
want
to
use
the
word
legacy,
but
all
of
the
assumptions
that
you
that
you
would
tend
to
have
in
in
a
pack-a-core
environment
and
that
to
see
what
the
differences
are
like
if
you're
bringing
in
a
firewall
as
a
cnf,
then
the
control
plane
requirements
are
very
different
from
something
like
like
a
packet
core.
E
So
we
so
we
should
make
sure
that
we
over
time
we
go
over
more
over
more
types
of
environments
to
to
see
not
only
not
only
how
are
the
same
but
we're.
Where
do
they
differ
as
well,
while
still
focusing
on
on
that
kubernetes
on
being
that
kubernetes
native
style.
B
Projects
open
source
products
that
are
also
open
source.
C
Not
only
necessarily
they
could
be
also
the
the
commercial
ones,
because
I
think
it's
probably
prevailing
model
for
those
bigger
functions,
but
for
that
we
would
need
the
developers
who
would
be
ready,
who
would
know
the
details
of
those
and
then
can
answer
the
the
questions
can
can
check
whether
the
patterns
that
we
are
defining
are
sustainable
for
that
function
or
or
not,
and
that
could
be
a
trigger
for
some
discussions.
C
Why
not,
and
and
what
holds
us
from
or
hold
that
particular
developer
vendor
from
adhering
to
these
best
practices.
They
were
just
really
looking
for
how
to
get
to
the
good
discussions
on
on
a
concrete
point,
as
we
could
start
from
the
open
source
ones.
B
So,
on
the
open
source
side,
we
can
probably
map
a
lot
of
the
applications,
but
those
may
those
are
likely
to
end
up
being
one
part
of
a
product.
B
B
The
list
that
I
put
in
there
that's
from
either,
if
we're
going
to
like
the
examples
from
cnf
testbed,
the
ex
the
list
of
examples
on
the
test,
suite
that
first
one
that
bill
it
open
up.
Where
you
go,
look
at
nsm
examples.
Those
are
all
the
smaller
components
and
stuff
you
may
see
for
the
most
part.
B
Unless
you
look
at
a
use
case,
I
mean,
if
you
look
at
a
use
case
instead
of
a
product,
then
we
could
probably
take
apart
the
different
pieces
and
go.
Oh
here's.
A
single
application,
like
the
vsp
use
case,
you're,
going
to
have
the
aaa
and
dhcp
and
a
lot
of
other
pieces
that
you
have
to
have
so
those
are
part
of
it.
And
then
you
have
like
the
different
gateways
and
those
could
be.
B
If,
if
you
thinking
about
a
kubernetes
based
deployment,
then
ideally
someone
could
you
could
have
different
vendors
providing
the
different
if
desired
you
could.
You
could
get
different
pieces
of
that
use
case
from
different
places,
so
you
may
actually
have
your
gateway
at
one
end.
That's
from
someone
and
you
don't
care
that
it's
not
from
the
same
vendor
because
it
all
works
together,
but
that
would
be
going
from
like
a
use
case
and
then
breaking
it
down.
B
B
I
mean
if
you
look
at
everything
we
need
to
be
able
to
have
access
to
code
more
than
having
people
available
to
answer
questions
and
talk
to
us
about.
Are
we
coming
up
with
best
practices
that
are
going
to
help
them
as
developers,
whether
that's
a
app
developer
or
platform
developers
or
ops
team?
Do
we
have
the
people
that
can
give
feedback
on
on
the
best
practices
that
we're
discussing.
C
C
On
the
other
side,
if
you're
looking
what
the
results,
what
these
best
practices
could
be
used
for-
and
there
was
a
discussion
around
the
pr
which
was
around
the
initial
framework,
yeah.
C
Leads
into
our
next
discussion,
yeah
potentially,
but
potentially
I
just
wanted
to
to
reflect.
Why
is
that
interesting?
So
if
we
have
a
good
job
done
here,
then
many
operators
will
take
this
list
like
today
for
a
security
things
around
kubernetes.
You
go
and
take
a
cis
list
and
say:
okay.
This
is
what
I
want
every
vendor
supplier
whatever
to
fulfill,
and
then
you
put
it
in
your
rfqs.
C
So
ideally,
if
we
did
a
good
job
after
some
time
and
have
a
set
of
best
practices,
many
operators
will
take
them
and
put
them
in
rfqs
when
they're
choosing
the
the
rfps.
When
they're
choosing
the
network
functions
cloud
native
network
functions
and
if
we
create
something
that
is
disqualifying
or
that
is
reducing
feasibility
for
many
network
functions.
Due
to
the
reasons
that
we
didn't
evaluate
on
a
practical
and
concrete
examples,
then
we
might
cause
some
some
some
challenges
or
some
problems
to
those.
C
So
that
would
be
really
interesting
to
have
a
dialogue
on
that
and
then
something
we
believe
is
is
a
best
practice
and
should
be
done.
A
certain
way
is
not
supported.
Broadly
then,
to
understand
why
and
then
see
you
know
is
that
them
a
best
practice
or
not
or
or
is
there
actually
advice
how
the
limitations
of
the
cns
could
be
overcome?
So
this
is
all
a
sense
of
of
searching
for
a
concrete
examples
and
then
concrete
dialogue
with
the
developers.
A
Yeah,
absolutely,
I
think
that
kind
of
so
if
anybody
has
any
ideas
of
who
wants
to
contribute
to
the
discussion
or
candidate
cnfs,
please
feel
free
to
add
it
to
the
discussion
item
here
in
the
repo
and
then
that
kind
of
leads
into
our
next
item
on
the
agenda
is
the
kind
of
the
initial
framework.
So
thanks
once
again
robbie
for
putting
this
together,
I
know
vlog.
A
Has
you
there's
a
couple
open
things
here,
but
has
everybody
had
a
time
to
look
through
this,
or
does
anybody
feel
like
they
need
like
more
time
to
look
through
this.
A
Okay,
so
I
think
we
can
probably
leave
it
open
one
more
week
and
try
to
get
it
merged
by
next
week.
Is
there
anything
that
anybody
wants
to
discuss
specifically
specifically
right
now.
G
G
I
I
think
I'm
hoping
this
pr
will
create
this
initial
framework,
so,
ideally
speaking,
this
will
be
the
the
framework
that
we
will
base
our
contribution
on.
So
I
really
encourage
everybody
to
look
at
that
and
once
approved,
I'm
hoping
to
follow
the
scheme
that
proposed
by
this
pr
so
make
sure
we
we
do
our
work
more
efficiently.
Afterwards,.
H
I'm
going
to
say
what
I've
been
saying
before,
which
is
this
limits,
our
scope?
If
we
put
it
the
way,
you
know
and
literally
first
time,
I've
read
it
for
apologies,
but
it
limits
our
scope.
If
the
first
thing
we
say
is
it's
a
question
of
making
sure
that
cns
are
compliant
against
best
practices,
because
the
best
practices
have
to
have
reasons
behind
them,
so
there
is
a
bigger
problem
to
solve.
Before
you
can
start
saying.
Cnf
should
be
built
this
way.
I
think.
A
So,
actually,
I
think
if
we
jump
down
to
the
actually
it's
not
here,
but
the
the
descriptions
it
actually
each
of
the
like
templates
actually
does
have
a
does.
Ask
you
to
list
the
reasons
why
each
of
them
should
be
so
so
there's
goals
non-goals
like
the
user
stories,
and
why
so,
if
you
think
something
else
should
be
included
in
here
well.
H
No,
I
mean
that's
fine,
but
normally
when
I'm
writing
a
document
like
that,
then
I'm
saying
here
is
my
motivation.
Here
is
the
goal
that
I'm
looking
for
here
is
the
thing
I'm
looking
to
accomplish
and
then
I
refer
out
to
why
that
goal
is
a
laudable
one.
Why
it's
the
one
that
we
should
be
aiming
for.
So
where
do
I
refer
out
to.
G
So,
just
just
to
clarify,
so
we
actually
decoupled
the
best
practices
from
the
actual
documents.
Would
that
really
allow
us
to
allow
anybody
to
propose
a
business
practice
and
as
long
as
they
can
prove
that
there's
enough
data
to
back
up
why
they
think
this
is
a
business
practice
it
it
will
go,
and
this
is
the
template
that
bill
is
showing
and
if
you
feel,
there's
any
more
information
you
would
like
to
see
for
any
best
practice
before
it
can
be
validated
and
it's
promoted
to
be
approved
as
a
best
practice.
G
H
Well,
well,
I
I'm
I'm
not
really.
I
think
I
mean
if,
if
what
we're
doing
here
is
best
practices,
that's
perfectly
acceptable.
I'm
saying
what
do
we
consider
authoritative
references
for
for
motivations,
so,
for
instance,
to
give
an
example?
H
If
I
assume
that
all
my
cnfs
are
going
to
run
on
malta's,
then
I
want
someone
to
have
made
a
an
informed
and
reasoned
choice
in
that
is
documented
for
with
their
reasoning
somewhere
else,
so
that
when
I
say
well,
I
test
it's
running
on
multis
like
this
that
and
the
other.
Then
I've
got
a
reason
to
be
testing
for
that
and
a
reason
for
the
best
practice
to
be
acceptable
bad
example,
but
I'm
trying
to
get
to
that
point.
I
I'd
like
to
add
one
more
thing
to
this
is
one
of
my
you
know.
One
thing
that
makes
me
nervous
is:
despite
this
whole
everybody
thinks
they're
agile.
Now
the
service
provider
world
likes
to
play
at
it,
but,
like
certain
things,
just
don't
conform
well
to
being
quote
unquote,
agile.
So
what
happens?
What
is
going
to
be
our
process
if
a
best
practice,
six
months
from
now
turns
out
to
not
be
a
best
practice
or
this,
and
that,
like?
How
are
we
going
to
prevent
like
the
road
that
etsy
went
downward?
I
They
wrote
a
bunch
of
arbitrary
things
down
at
the
beginning,
and
then
it
was
like
we
were
never
ever
ever
changing
these
especially
kind
of
to
ian's
point
of
view
saying
that
you
should
be
building
to
these
best
practices,
and
one
of
them
is
debunked
like
how
do
we
keep
developer
trust
when
we
say
we
need
to
like
go
back
on
this
or
we
need
to
modify
like
you
might
have
to
start
changing.
You
know
x,
y
or
z,
part
of
your
development.
E
So
if
this
is
direction
we're
going
to
take,
I
think
that
we
definitely
need
to
make
sure
we
establish
a
set
of
principles
and
say
like
these
are
things
we
tend
to
look
for
in
general,
regardless
of
technologies
such
as
the
system
should
be
able
to
withstand
a
a
container
or
a
pod
dying
without
losing
service
as
a
without
losing
the
significant
service
or
degradation,
or
we
can.
We
can
come
up
with
other
general
high-level
things,
but
when
it
comes
down
to
low-level
implementation
details,
we
have
to
be
a
little
bit
careful
here.
E
To
give
you
a
really
good
example,
then,
and
not
in
the
not
as
much
in
the
container
space.
But
let's
say
you're
talking
about
like
best
practices
for
maintaining
a
car.
You
may
say
best
practice
in
maintaining
a
car
is
to
make
sure
that
you
fill
it
with
the
right
set
of
gas
and
and
fill
it
with
the
right
set
of
oil.
But
then
what
does
that
mean
if
you're
driving
a
tesla?
E
It's
like
you,
you
end
up
with
a
different
set
of
best
practices
for
for
it,
even
though
they
are
they're
still
fundamentally
a
a
car,
and
so
we
need
to
be
careful
that
we
that
we
don't
fall
into
the
same
trap
and
instead
we
we
list.
What
is
the
principle
we
want
to
make
sure
this
thing
is
well
maintained,
or
we
want
to
make
sure
this
thing
is
well
is
able
to
scale
or
so
on.
E
If
your
environment
is,
if
your
cnf
is
multis,
and
it
has
these
conditions,
then
these
best
practices
occur
and
that
there's
a
set
of
appropriate
conditions
so
that
when
someone
comes
along
with
something
they
want
to
install
with
with
banam
or
they
want
to,
or
maybe
something
that
bypasses
all
of
that
and
adds
it
in
with
nsm,
then
you
know
in
what
context
that
best
practice
applies
in
order
to
in
order
to
apply
it
you're
getting
with
something.
E
That's
a
bit
concrete
and
we
can
circle
around
and
say
in
order
to
achieve
this
principle.
These
are
these
are
requirements
or
not
requirements.
It's
too
strong
of
a
word,
but
these
are
best.
These
are
some
best
practices
that
may
exemplify
this
particular
property.
It's
not
the
only
path,
there's
other
paths
that
may
be
that
may
be
appropriate
that
are
not
listed,
but
there
are
things
you
can
use
as
a
reference
to
to
get
there.
So
if,
if
we're
gonna
head
towards
that
that
practice,
we
we
we
may
use
something
like
that.
I
I
My
big
fear
is,
is
it'll,
be
kind
of
like
what
we
had
in
vnfs,
where,
like
the
quote,
unquote
best
practices,
the
requirements,
the
standards,
etc,
weren't
really
feasible
in
the
real
world,
and
so
most
developers
rolled
their
eyes
and
just
said,
I'm
going
to
build
what
I
think
works
right
and
if
we
yank
the
rug
out
from
people
a
bunch
they're,
probably
not
going
to
take
our
group
very
serious,
because
it'll
be
impossible
to
adhere
to
so
I'm
just
kind
of
curious,
like,
as
you
know,
let's
say
we
adopt
robbie's
framework,
which
is
fine
with
me.
I
I
don't
like
daniel
would
like
to
read
it
one
more
time,
but
let's
say
we
go
down
that
path.
I
just
want
to
make
sure
that
we
leave
ourselves
out
that
we
have
the
ability
to
self-reflect
and
correct
things
as
this
space
evolves.
If
it,
you
know,
new
technology
comes
out
that
maybe
even
makes
us
re-evaluate
a
principle.
I
I
would
like
us
to
like
have
a
plan
for
that
in
advance
versus
you
know.
We
get
something
that's
broken
later
on
and
we
don't
have
a
way
to
self-correct.
E
They
were
just
added
in
on
the
off
chance
that
that
they
may
be
useful,
and
so
we
we
should
be
careful
in
in
this-
that
we're
not
falling
into
the
same
into
the
same
trap,
because
we
want
to
list
things
that
are
common,
and
one
of
the
things
that
we
could
do
is
put
a
priority
towards
things
that
we
see
in
in
development
or
practice
where,
if
we
see,
if
we're
not
seeing
any
active
implementation
or
we're
not
seeing
any
active
development
but
we're
something
that
is
aspirational,
then
we
should
explicitly
state
that.
E
H
So
one
way
you've
got
two
things
there.
I
think
one
is:
where
do
we
source
our
best
practices
from
again?
You
know
what
evidence
we
have
that
this
would
make
a
good
best
practice
and
the
other
is
given
a
best
practice.
How
do
we
get
feedback
on
it
so
that,
if
it
turns
out
that
it's
counterproductive,
we
remove
it
from
our
preference
list.
G
So
it
seems
to
me
we
need
around
the
process
of
approving
a
best
practice
or
change
it
and
just
put
some
criteria
around
them.
B
I
don't,
I
don't
think
from
the
if
you
look
at
the
perspective
of
like
cap,
the
kubernetes
enhancement
proposals
or
python
or
ruby
rails,
where
different
projects
that
are
have
a
healthy,
organic
way
of
adding
new
things
and
modifying
new
things.
It's
part
of
the
process.
B
So
if
you
are
saying
that
something's
problematic,
you
ideally
see
it
before
it
fully
gets
to
the
point
of
implementation
as
as
a
enhancement.
So
for
us
that
would
mean
before
we
endorse
it
as
a
best
practice,
but
for
those
that
you
don't
what
happens?
Is
they
have
a
history
on
a
cap
and
they
go
we're
refactoring
this
or
they'll
have
similar
rfcs
you'll
have
a
new
one
that
comes
out
that
addresses
things
that
are
missing,
and
then
you
can
also
deprecate
likewise
rfcs,
where
one
is
completely
deprecated
and
no
longer
recommended.
B
I
don't
think
from
that
perspective
that
we
have
a
problem
as
long
as
we
don't
add
additional
rules
and
and
process
that
blocks
those
things.
Ideally,
anyone
could
bring
something
up
and
and
start
talking
about
an
existing
best
practice
and
problems.
We
can
move
that
into
a
discussion,
start
working
through
it.
If
we
see
it
as
a
problem,
then
we
can
move
forward
on
potentially
deprecating
a
best
practice
or
maybe
modifying
it,
and
jeffrey
you've
talked
about
adding
context
saying
where
it
may
be
a
problem
in
some
situations,
but
perfectly
fine
in
others.
B
So
that's
something
that
we
may
do
after
the
fact.
You
may
have
a
best
practice
that
everyone
agreed
to
looks
great
and
then,
as
we
get
going
either
because
things
change
in
the
world
or
we
just
hadn't.
Had
someone
speak
up,
you
find
it.
It
doesn't
work
in
some
situations
and
we
can
always
add
to
the
best
practice
content
so
that
that's
known.
I
Yeah,
I
don't
disagree
that
certain
groups
do
this
better
than
others.
Like
I
said.
The
big
thing,
though,
is
there
could
be
like
big
horse
corrections
like
anybody.
Who's
followed
ipv6
for
a
really
long
time
in
kubernetes
knows
that,
like
we
all
know
that
the
shoe
is
eventually
going
to
drop
and
it's
going
to
be
awkward
like
there's
disagreement
on
how
ipv6
should
be
implemented
just
networking
in
general.
I
You
know
it
was
very
web
centric
at
the
beginning
and
then
other
people
wanted
to
use
kubernetes
for
things
and
they're
like
oh
now,
we
need
things
like
egress
gateways,
all
this
stuff
right
and
you
know
I
would
say
that,
like
cube,
sig
and
others
have
done
a
good
job
of
you
know
addressing
these,
but
that
doesn't
mean
that,
like
the
transitions
have
been
as
painless
as
we
would
like
them
and
like
I
said,
even
if
we
know
that
there's
good
models
for
us
to
follow,
we
should
pick
one
of
those
models
and
call
it
out,
because
I've
also
seen
other
groups.
I
You
know
just
assume
that
yeah
we'll
be
fine
and
then
it
didn't
work
out
the
way
they
wanted
to.
Like
technical
debt,
you
know
mounted
up
to
the
point
where,
like
maybe
we
just
need
to
completely
start
from
scratch.
Things
like
that.
So,
like
I
said
I
just
maybe
some
of
this
is
a
little
bit
of
anxiety
based
on
past
experiences,
but,
like
you
know,
I
know
at
some
point.
I
I
have
to
look
at
how
we're
going
to
do
ipv6
and
kubernetes
and
then
well
specifically,
dual
stack
and
additionally,
you
know
I've
seen
other
organizations
where
they
didn't
have
a
smooth
process
to
you
know
something
like
ruby
on
rails
or
something
where
it
was
much
much
more
painful
or
they
just
said
it's
not
worth
it.
We're
just
not
going
to
change
and
everybody's
going
to
keep
running
off
the
cliff
like
a
living.
E
Yeah
the
kubernetes
example
also
has
the
added
constraint
that
they
had
some
a
single
major
code
base
to
to
work
around
with
an
initial
set
of
use
cases.
I
think
the
standard
kubernetes
workloads
that
you
see
and
we
we're
gonna,
run
into
a
few
problems
with
that
and
that
we
don't
have
such
a
such
a
thing
like.
E
We
can't
there's
no
reference
architecture
that
we
will
be
able
to
point
to
and
say
this
is
the
one.
This
is
the
one
path
like
we're
already
seeing
a
a
variety
of
different
approaches
that
that
are
occurring
each
with
different
set
of
of
different
principles
and
constraints
that
that
are
being
deployed
and
so
like.
We
that
that's
part
of
the
reason
I
mentioned
about
the
the
conditions
before
as
well
like
if
you're
running
in
this
style
of
environment,
then
what
are?
What
are
possible?
E
E
If
I
choose,
if
back
in
the
day,
if
I
chose
flannel
as
my
cni
versus
maybe
openshift
cni
versus
something
like
you
know,
some
of
the
some
of
the
other
cni's
that
have
come
along,
such
as
weave
that
they
ended
up
with
significantly
different
best
set
of
practices,
even
just
to
maintain
it
much
less
how
they
approached
the
development
of
their
of
their
environment,
and
all
of
them
were
rational
ways
to
to
approach
it.
E
They
just
made
different
decisions
based
upon
their
requirements
and
technologies,
and
we,
if
you,
if
you
look
at
the
best
practices
that
came
around
kubernetes,
they
ended
up
with
three
simple
rules
and
those
three
simple
rules
where
nodes
can
talk
to
other
nodes.
Pods
can
talk
to
pods
and
nodes
can
talk
to
pods,
and
as
long
as
you
met
those
three
conditions,
then
your
has
a
cni
along
with
some
of
the
basic
contracts
that
were
added.
E
Like
you
give
your
id
back
and
a
couple
other
minor
things,
then
you
were
pretty
much
set
and
good
to
go
and
it
was
hands
off
primarily
on
how
do
you
actually
achieve
it,
and
I
think
we're
we're
trying
to
be
much
more
aggressive
here
in
saying
that.
Well,
we
want
to
state
these
are
the
best
practices
and
then
we
say:
okay
well
best
practices
in
relationship
to
to
what
and
that's
why
we
want
to
start
with.
What
are
the?
What
are
the
principles
like
we
want?
E
We
want
to
be
horizontally
scalable,
we
want
to
be
robust,
we
want
to
be,
and
the
question
even
comes
down
to
why,
like
ian,
had
a
really
great
point
from
previous
conversations,
we
had
that
if
you
delivered
a
a
box
and
that
box
had
met
all
of
your
requirements
for
uptime
and
you
could
access
it
through
a
very
common
api,
do
you
care
whether
or
not
it's
if
it's
designed
in
a
very
specific
way,
and
so
so
maybe
we
should
even
get
down
to
the?
E
E
And
then
we
can
say
if
you
are
implementing
it
this
with
these
constraints,
then
these
are
some
of
the
best
practices
and
go
tap
some
of
the
communities
to
to
go
deal
with
that.
So
we
can
go
tap
the
the
multis
and
the
data
and
the
nsm
communities
and
say
well
you're,
going
to
give
us
some
examples
of
things
that
exemplify
best
practices
and
go
and
talk
about
how
those
how
those
are
approached
and
also
other
areas.
We
can
also
take
a
look
at
them
from
use.
E
Cases
like
the
requirements
of
putting
together
a
firewall
or
a
vpn
and
managing
of
kubernetes
based
firewall
or
vpn,
are
going
to
be
much
different
from
best
practices
surrounding.
How
do
you
maintain
a
evolved
packet
car
on
on
your
system?
The
the
requirements
are
are
fundamentally
different
down
to
the
point.
C
Speaking,
one
comment
on
the
depreciation
of
the
best
practices:
that's
a
very
valid
aspect
that
we
have
to
take
with
very
carefully
and
very
seriously,
especially
due
to
that
past
experiences,
not
only
with
with
etsy
and
vnf,
but
many
other
approaches
like
that.
C
This
was
one
of
the
reasons
that
motivates
me
to
bring
that
first
point
in
as
long
as
we
have
a
concrete
functions
and
concrete
pieces
of
code
in
the
discussion
and
having
it
bidirectional
dialogue
or
being
ready
to
depreciate
deprecate
certain
best
practices.
If,
in
the
dialogue
we
found
out
okay,
it's
really
blocking
meaningful
things
and
it
doesn't
contribute
to
you
know
better
sla
or
better
uptime
and
so
on.
C
Then
it's
up
to
community
to
really
focus
on
deprecating
that,
but
we
will
only
find
or
mostly
find,
that
by
confronting
the
rules
with
the
concrete
examples,
the
problem
with
etsy
was
that
there
was
a
lot
of
writing
in
a
point
in
time,
as
was
rightfully
said,
and
that
there
was
no
willingness
on
consideration,
but
we
were
just
pushing
or
not
just
pushing,
but
there
was
a
lot
of
like
okay.
This
is
the
framework
please
fit
to
that,
and
then
the
the
feedback
from
the
developers
that
was
set
here
were
rolling
their
eyes.
C
This
rolling
of
ice
didn't
end
up
in
the
process
of
reviewing.
Does
that
what
we
do
or
what
they
do
there
makes
sense
and
how
it
has
to
be
reevaluated.
That's
very
important
to
to
factor
in
here
and
another
piece
that
that
was
mentioned
is
like
black
box
thing,
and
I
I'm
reiterating-
and
I
was
reiterating
in
a
chat.
C
There
could
be
two
purposes
of
that.
One
is
completely
developer
centric
and
that
should
go
like
how
to
use
cloud
native
patterns
and
how
to
use
kubernetes
to
the
maximum
and
possible
extent
to
make
a
best
function
package
it
in
the
box
and
deliver
it
from
the
operator
side
from
the
side
of
the
of
the
actors
that
are
consuming
that
that's
still
called
a
black
box.
You
can
put
whatever
asic's
proprietary
hardware
in
it.
That
would
be
all
all
same.
C
The
other
approach
or
other
way
to
do
that
is
really
saying.
Okay,
do
we
as
operators,
I'm
talking
from
the
operator
angle,
wanna,
establish
a
generic
cloud
layer
for
those
functions
and
onboard
the
network,
functions
on
that
cloud
layer
and
give
the
functionalities
and
the
possibilities
to
those
functions
to
be
able
to
to
run
as
they
were
supposed
to
run,
and
I
think
the
the
the
value
of
doing
a
cloud
native
principles
is
at
least
for
for
that
perspective
of
operator,
that
I
have
a
generic
or
more
or
less.
C
C
Just
wanna
wanted
to
reflect
on
that
because
for
a
black
box
I
think
black
posts,
whatever
it
is
inside.
Nobody
wants
to
care
except
developers
who
are
making
that
black
box
to
be
the
best
possible.
H
Sp
speaking
as
the
supplier
to
a
bunch
of
very
inquisitive
customers,
I'm
not
sure
that's
true,
but
perhaps
what
we're
saying
here
is
rather
than
the
what
the
document
currently
says.
You
know
we
will
define
best
practices
in
light
of
other
people.
Other
definitions
of
cloud
native,
we
should
say
we
will
define
best
practices,
that's
one
avenue
of
attack,
but
we've
got
other
things
to
deal
with
as
well.
I
think
we're
ruling
things
out
that
we
should
have
within
our
remit.
H
So
I
mean
we've
the
the
points
keep
coming
up
there
right,
that
we
don't
have
a
platform
definition,
because
we
don't
know
what
good
cnf
is.
You
know
a
well-behaved
cnf
following
a
standardized
and
singular
platform
definition
as
an
example.
We
talk
about
cloud
native
as
if
it
has
meaning
without
context.
You
know
the
words
mean
we
know
exactly
what
a
cnf
cloud
native
cnf
looks
like
and
those
principles
exist
elsewhere,
and
I
don't
think
they
do
so.
H
Rather
than
saying
we
will
do
the
lowest
layer
of
this
we'll
do
the
the
implementation.
The
thing
that
describes
here
is
to
see
here
is
the
cloud
native
best
practice
here
is
how
you
demonstrate
that
it
exists
in
a
given
cnf.
We
also
say
here
is
not
just
the
test
for
the
thing
we're
looking
for,
but
here
is
why
that
thing
is
a
best
practice
in
the
first
place.
Here
is
our
thoughts
on
why
it
should
be
a
best
practice.
Not
necessarily
you
know,
hoping
that
turns
up
in
another
group.
B
Those
the
why
why
something
should
be
a
best
practice
is
explicitly
part
of
the
proposal
process,
so
starting
with
the
discussion
board,
so
you're
discussing
something-
and
the
discussion
board
of
course,
can
be
other
things,
so
we
have
like
the
actors
and
stuff,
but
the
when
you're
someone
is
bringing
up
a
potential
best
practice
or
maybe
within
a
discussion.
It
is
ideally
part
of
the
conversation
would
say
here
is
why
we
think
this
is
a
best
practice.
Yeah.
H
You
have
to
build
down
to
the
level.
What
we
want
to
be
at
here
are
testable
things.
We
can
examine.
B
If,
if
we
were
building
all
of
this
from
scratch,
if
you
just
came
in
and
said
we're
going
to
build
software
and
operators
just
start
using
it,
and
just
you
want
things
to
run,
okay,
that's
all
we
we're
not
doing
that.
We're
not
we're
not
starting
completely
from
scratch,
we're
we're
building
off
of
existing
applications.
B
So
that's
related
to
putting
the
discussion
forward
on
cnf
candidates.
So
that's
working
from
that
level
backwards.
You've
already
listed
in
the
actor
and
hold
on
a
moment,
and
if
you
go
look
at
the
actor
discussion,
one
of
the
items
that
was
brought
forward
was
platform
developers
or
vendors.
Whatever
you
want
to
call
those
wherever
they
are,
so
those
people
would
be
involved.
Architects
designing
from
maybe
within
the
a
a
at
an
actual
service
provider
that
may
be
designing
the
overall.
B
So
you're
going
to
have
all
of
those
people
engaged,
but
it
doesn't
mean
that
we
have
to
have
all
of
that
done
before
we
even
start,
because
we
already
know
that
part
of
it's
going
to
be
based
off
of
what's
out
there.
So
the
the
bgp
speaker
are
we
going
to
say
those
are
no
longer
useful
immediately.
H
I
I'm
fine,
but
yes,
if
you
want
to
design
this
stuff
and
you're
a
little
bit
short
on
the
on
the,
why
of
what
you're
doing
bgp
speaker
as
an
example
right,
then,
where
would
I
put
down
the
y?
Where
do
I
put
that
down-
and
I
don't
mean,
as
as
in
the
same
way,
that
I
try
not
to
write
code
and
hope
everybody
understands
what
the
requirements
were,
that
drove
me
to
write
it,
I'm
saying
where
would
the
abstract
requirements
go
when
we
get
those
actors
together.
J
J
J
And
you
get
user
stories
right,
you
say
this
is
a
user.
This
is
what
they're
doing.
This
is
a
problem
whatever
it
is,
and
now
you're
going
to
build
your
requirements
based
on
that
user
story.
What
where
you
got
the
requirements
which
could
come
after
the
user
story?
You
can
look
at
the
user
story
as
a
requirement
either
way.
But
what,
where
are
you
not
capturing?
What
you
you
are
talking
about.
J
H
I'm
saying
I'm
saying
the
conclusion
stands:
independent
of
the
user
story.
So
if
we
have
a
user
story,
would
it
not
make
more
sense
to
keep
it
separate
from
the
conclusions
we
draw
from
it
rather
than
embed
it
in
every
single
conclusion,
because
the
proposals
we
seem
to
have
here,
the
the
things
we
will
be
filling
out
as
templates
are
conclusions,
recommendations
the
final
and
the
final
element
of
the
implementation.
J
So
fair
enough,
if
you
were
so
if
the
user
stories
were
separate
right,
but
you
referred
to
the
user
stories
and
that's
what
we
say:
okay,
here's
our!
Why
you
need
to
have
a
real
world
description
of
something
you
want
and
point
back
to
that
and
then
you
have
the
and
then
you
point
to
it
instead
of
having
it
in
directly
embedded
in
there
that
would
kind
of
satisfy
what
you're
talking
about.
H
Yeah
effectively
having
a
home
for
those
things,
independent
of
the
the
things
that
we,
the
the
recommended,
you
know
tests
or
things
to
do,
and
tests
that
satisfy
that
user
story
having
the
user
stories
stand
independent
because
I
think
that
means
that
the
user
story
will
be
more
yeah.
Fine,
it
won't
have
conclusions
of
its
own,
but
it
will
be
hopefully
something
that
people
who
don't
necessarily
care
so
much
about
exactly
what
we're
testing
about
cnf
we'll
actually
be
able
to
read
it
and
make
sense
of
it.
J
You
have
certain
principles
of
cloud-native
principles,
so
on
so
forth,
and
we
say:
okay
well,
if
you're
wanting
to
have
this
type
of
architecture
and
these
types
of
trade-offs
that
go
with
this
architecture,
are
they
compatible
with
this
user
story?
No
drop
them
off.
You
can't
implement
it
or
you
can.
Whatever
I
mean,
it
seems
like
that.
You
know
this
is
a
you
know,
a
cat
in
you
know
chicken
and
egg
situation,
which
is
fine,
but
yeah
user
stories
seem
to
me
capture
everything
you're
talking
about.
H
B
I
like
the
idea
ian
of
having
a
whole
set
of
user
stories,
that
people
can
contribute
to
and
and
maybe
more
than
people
just
being
able
to
find
it
separately
would
be
people
that
want
to
contribute
user
stories,
but
don't
really
know
it.
They
they're,
maybe
they're,
have
more
experience
on
the
user
story.
Writing
those
and
less
experience
on
helping
with
build
a
best
practice
or
discussing
the
implementations.
B
So
it
helps
with
that.
I
don't.
I
wouldn't
want
to
stop
people
from
getting
started.
That
was
the
whole
point
with
doing
this,
which
ties
in
with
having
the
user
story
embedded,
but
I
would
say
whether,
if
someone,
if
someone
well,
if
someone
starts
a
proposal
for
a
best
practice,
they
should
it's
it's
required
actually
before
it's
going
to
make
it
that
they
need
to
tie
that
to
the
user
story
yeah
and
that
can
always
be
copied
out.
If
someone
starts
with
the
user
story,
then
great
just
go
to.
J
H
Yeah,
that's
fine!
If
you
consider
what
we
have
here,
we
have
a
git
repo
and
every
git
repair.
I've
ever
worked
in.
You
can
commit
two
changes
in
two
files
at
the
same
time.
So,
if
you've
got
a
best
practice,
you
wish
to
recommend
against
a
user
story
that
no
one's
ever
thought
of
before
you
can
commit
the
best
practice
and
the
user
story
in
a
single
change.
It
just
isn't
in
a
single
file
anymore
right.
H
You
commit
the
best
practice
and
the
reference
to
it
in
the
user
story,
but
it
gives
you
three
options
now,
rather
than
one.
I
can
commit
a
best
practice
based
on
user
story
that
somebody
else
documented.
I
can
commit
a
user
story
even
if
I
don't
know
what
best
practices
that
implies
and
I'm
leaving
other
people
to
tell
me
or
I
can
commit
the
whole
thing
as
a
as
a
chunk
and
people
can
review
it
in
that
light,
whereas
what
we
have
at
the
moment
doesn't
seem
to
leave
us
with
quite
those
options.
A
Yeah,
you
know,
I
think
I
say
what
you're
saying
I
see
what
you're
saying.
Would
you
want
to
come
up
with
like
a
proposal
similar
to
like
robbie's
for
the
usual
user
stories.
H
Yeah,
I
think
we
can
build
on
robbie's
patch,
and
we
can
say
you
know
we
we
take
two
streams
of
information.
This
part
is
our
responsibility
is
x.
This
part
of
our
responsibility
is
y,
and
here
is
the
process
for
both
of
those
things.
So
if
we
start
there
and
then
we
want
a
template
for
what
user
story
is
including
audience
and
so
on,
which
would
be
the
next
part
of
that.
B
Okay,
perfect,
is
there
a
would
it
be
all
right
if
we
get
this
merge
from
robbie
in
place
and
then
do
a
new
pr
on
top.
B
Okay,
well
I'd
say
everybody,
that's
interested
in
helping,
please
go
through
the
pr
and
let's
try
to
get
it
merged,
we're
we're
not
trying
to
get
something
perfect
today
or
this
week,
and
and
it's
sitting
there.
This
goes
back
to
the
comments
earlier
about.
What
do
we
do
if
there's
a
best
practice
that
needs
to
be
updated?
B
None
of
this
should
be
thought
of
as
final.
It
should
all
be
thought
of
as
we're
doing
we're
doing
what
we
understand
to
be
best
today
and
we're
going
to
keep
updating
it
every
day
going
on,
but
if
there's
something
in
what's
currently
there
and
that
you
think
needs
updated
okay,
but
ideally
we
can
keep
having
smaller
prs
that
get
merged
sooner
so
they're
available
yeah.
H
I
mean
it
certainly
in
the
future.
That's
obviously
the
case
we're
trying
to
make
this
so
that
everybody
knows
what
self-contained
change
looks
like,
so
that
makes
more
sense
right
now
we're
busy
defining
our
outlook
on
the
world.
So
while
I
think
I'm
all
right
with
what
robbie's
saying
I
want
to
read
it
more
properly
because
I
don't
want
it
to
be,
you
know
I
want
to
make
sure
we're
getting
somewhere
in
the
right
direction.
H
A
So
sure
yeah,
so
I
think
it'd
be
great
if
we
can
all
take
the
next
week
to
review
robbie's
pr
and
then
we
can
continue
the
discussion,
then
so
thanks
everybody
for
joining
today.
I
really
appreciate
the
discussion.
I
think
you
know.
I
really
appreciate
your
idea
on
splitting
the
user
story
and
the
best
practice
from
each
other.