►
From YouTube: CNCF CNF WG Meeting - 2020-12-14
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
A
A
Meeting,
oh,
I
see
bill,
you
just
dropped
the
meeting
at
the
same
time,
hi
bill
meeting
notes
are
in
zoom
chat.
You
can
add
your
name
and
any
topic
that
you'd.
A
B
Thanks
for
anyone,
that's
joining
right
now,
there's
a
link
to
the
meeting
minutes
in
the
chat.
Please
feel
free
to
add
your
name
there
and
then
we'll
get
started
in
about
two
minutes.
B
C
Okay,
thanks
everybody
for
joining
today.
C
This
is
the
cnf
working
group
weekly
meeting
thanks
for
joining
things
that
we'll
be
going
over
today
is
the
the
process
and
the
structure
for
ideas
to
become
adopted,
best
practices
and
kind
of
jump
into
some
of
the
issues
that
we
have,
and
so
the
re
I
guess
before
we
jump
in,
is
there
anything
anyone
else
wants
to
add
to
the.
C
C
Okay-
and
maybe
this
is
sorry-
this
is
ruben
speaking
quick
question,
so
the
goal
is
really
to
discuss
how
to
turn
lots
of
the
discussions
we
had
into
something
more
actionable
right,
yeah,
that's
correct
and
then
that
feeds
for
me.
C
Yeah,
so
I
guess
reuben
to
jump
right
off
of
your
comment
is,
I
think,
what
a
lot
of
people
have
been
seeing
is
that
there's
been
a
lot
of
conversations
flying
around
both
in
this
meeting
on
the
slack
channel
in
various
different
ways,
but
it's
been
a
little
bit
hard
to
make
them
actionable
in
terms
of
how
we
want
to
move
forwards
with
them
into
kind
of
like
proposals
for
best
practices.
C
So
we
do
have
the
like.
The
best
practices
like
like
temp
or
like
proposal
template,
but
as
so
far
no
one
has
really
like
opened
that
open
that
up,
and
so
what
we're
thinking
of
the
actual
process
is
kind
of
like
providing
like
a
smoother
onboarding,
with
first
kicking
off
discussions
here
in
the
cnf
working
group
discussions
board,
and
we
can
actually
see
a
couple
different.
C
B
C
B
C
Look
at
the
different
best
practices
that
we
have,
rather
than
someone
to
have,
having
a
complete
idea
formed,
and
what
this
allows
us
to
do
is
to
kind
of
iterate
on
the
idea
before
we
need
to
come
up
with
a
more
formal
proposal,
and
so
in
this
way,
all
the
ideas
around
a
certain
best
practice
can
be
kind
of
contained
in
one
place,
and
once
kind
of
the
group
thinks
that
there's
enough
information
and
discussion
around
a
certain
best
practice,
then
a
more
formal
proposal
can
be
made.
C
So
if
you
think
about
it,
kind
of
like
the
the
proposed
process
right
now
would
be
first
like
either.
Would.
E
Be
starting
something
on
this
discussion
board,
creating
discussion
discussing
it
in
this
meeting,
generating
enough
ideas
and
interests,
and
then
the
next
step
would
be
actually
defining
a
actual
proposal
and
in
this
way,
instead
of
having
a
whole
bunch
of
conversations
in
slack
that
you'd
have
to
search
through
each
best
practice
kind
of
has
something
behind
it.
E
E
Or
taylor,
do
you
want
to
jump
in?
Oh
they
just
to
add
a
little
bit
to
it.
E
So
the
I
don't
know
that
every
every
topic
in
here
is
going
to
become
best
practice,
especially
ones
that
are
meant
to
be
like
defining
the
telecom
actors,
so
any
anything
that
we're
discussing
where
it's
going
back
and
forth,
and
we
keep
asking
let's
try
to
get
it
in,
so
that
everyone
is
getting
those
seeing
the
conversations
whether
those
are
on
the
meetings
or
in
slack
it's
fine
to
keep
having
them,
of
course,
any
any
area,
but
try
to
capture
something
so
that
we
can
have
that
shared
understanding
and
that
one
of
the
main
reasons
to
get
it
in
here,
besides
making
sure
that
everyone
can
see
it
is
to
make
the
hurdle
for.
E
I
guess,
sharing
the
ideas.
Broader
is
the
formal
adding
of
proposal
may
feel
like
you,
don't
want
to
do
it
yet
because
you
don't
have
all
the
information
so
to
lower
that
hurdle.
For
that,
and,
of
course,
if
anyone
sees
something
that
they
feel
like
there's
enough
content,
I
think
that
we
can
put
something
forward.
We
have
all
the
references,
we
have
the
use
cases
we
have
all
the
stuff
that
we
feel
is
necessary
to
communicate
that
this
is
a
best
practice
that
we
want
to
put
forward
then
open
a
pr.
E
E
Hey
taylor
bill,
hey
joe
hey,
so
one
thing
I
would
like
and
it's
going
to
be
contentious
and
rough,
but
I
think
it's
necessary
before
we
start
defining
best
practices.
Is
we
put
in
our
charter
that
one
of
the
things
that
this
group
would
do
would
put
forth
our
definition
of
what
a
cnf
is?
I
think
that's
really
important.
E
I
know
I've
talked
to
you
a
little
bit
about
this
taylor,
but
I'd
like
to
you
know,
put
it
in
front
of
the
group
is
if
we
don't
have
a
definition
for
what
we're
you
know,
proposing
best
practices
for
there's
a
lot
of
ambiguity
that
can
get
us
into
trouble.
For
instance,
like
you
know,
there's
best
practices
around
the
amount
of
privilege
that
a
container
gets
and
we
could
get
into
specific.
You
know
nuanced
discussions.
A
E
Orchestration
for
say,
the
infrastructure
comes
along
with
the
cnf
itself.
If
we
don't
say
that
you
know
those
are
two
separate
things
and
some
cnf
developers
put
their
orchestration
pieces
in
with
the
cnf
and
bundle
it
all
together.
Some
don't.
F
We
get
into
this
weird
thing
where
we
say
it's
a
best
practice
to
not
have
you
know
privileged
containers
and
then
all
of
a
sudden
we're
in
a
scenario
where
we
have
a
container.
That's
you
know
an
orchestration
platform.
That's
been
quote
unquote,
labeled
as
cnf,
because
it
was
you
know
just
bundled
that
way,
and
it's
now
you
know
breaking
a
best
practice,
because
it's
provisioning
block
storage
for
me
or
something
right
like
so
I
I
think
we
need
to
make
sure
that
we
a
define.
E
You
know
what
we're
saying
this
is
a
best
practice,
for
you
know.
Is
it
a
single
container?
Is
it
a
collection
of
micro
services
like
everybody
has
a
different
opinion,
but
it
would
be
nice
if
the
cnn
cncf
gave
us
like
a
this
is
what
we
think
it
is
and
then
from
there
we
can
provide
context
in
these
best
practices
to
the
type
of
workload
that
the
best
practice
applies
to,
because
I
mean
obviously
there's
going
to
be
times
where
you
want
a
container
to
do
certain
things
or
you
can
just
make
it.
E
E
Something
that
sounds
good
jeff.
I
think
that
there
was
something
that
you
talked
about
last
week
in
chat
about
exceptions
to
so
that.
B
Contest
so
this
would
be
tynan
with
what
context
do
we
need
to
know
about
a
best
practice
so
that
you
know
how
it
applies
and
it
seems
like
that
would
be
related
yeah
well,
so
yeah
context
how
it
applies,
and
then
I
mention
exception
and
then
I'll.
Let
ian
speak
to
it,
because
ian
was
actually
talking
about
like
a
formal
process
he's
used
in
the
past.
But
the
big
thing
is
right:
ism
we
don't
want
something
to
instantly
be
disqualified.
If
it's
a
really
good
idea,
because
it
breaks
the
current
best
practice
and
maybe.
G
That
best
practice
wasn't
exactly
supposed
to
fit
to
what
that
specific
container
was
trying
to
do
so,
but
yeah
exceptions
in
context.
I
think,
are
super
important,
because
if
not,
we
end
up
with
these
really
broad
brush
strokes
that
either
limit
what
we
can
do,
or
it
leaves
things
so
open
to
interpretation
that
you
know
we
could
both
be
quote-unquote
following
a
best
practice
and
have
completely
you
know,
polar
opposite
results.
G
So
I
mean,
when
I
did
this
in
well,
it
wasn't
say
it
was
safety,
mitigating
which
is
a
little
bit
of
a
a
get
out
clause
for
the
the
companies
I
was
working
for,
but
safety,
mitigating
software,
then.
C
C
Well,
among
other
things,
for
us,
it
would
mean
we
could
evolve
over
the
course
of
time.
The
best
practice
list
would
not
be
a
list
that
we
couldn't
change
because
it
was
already
in
use.
We
could
come
up
with
a
v2
or
a
context-specific
list
for
certain
types
of
application
or
certain
circumstances,
and
I'm
thinking
about
this,
because
you
know
it's
nice
to
think
here-
we're
in
a
relatively
academic
environment
where
we're
talking
about
stuff
that
doesn't
change
the
world
or,
alternatively,
the
world
will
just
naturally
comply
to
it.
G
C
Turns
out
to
have
been
not
a
good
choice
in
in
practice,
this
seems
like
the
way
to
make
sure
we
could
potentially
evolve.
E
E
E
Which
can
also
be
read
as
saying
you
know
if
you've
got
a
best
practice
that
you
think
is
you
know
the
best
we
can
do
today
as
opposed
to
the
best
we
might
ever
do
or,
alternatively,
a
best
practices
that
doesn't
apply
in
every
circumstance
all
the
time.
E
That's
still
not
an
excuse
not
to
write
it
down.
You
should
write
it
down
and
put
it
in
and
we
will
find
the
moment
to
apply
it
and
if
it
turns
out
it
gets
outdated.
We
will
have
a
means
of
of
saying.
Actually
it
turns
out.
We
won't
be
doing
that
long
term.
After
all,
so
get
more
ideas
in
there
and
we
can
choose
our
baseline.
It's
not.
We
haven't
written
something
in
stone
in
such
that
it
can
never.
It
can
never
be
altered.
G
E
I
was
wondering
whether
you
could
recommend,
because
I
think
we
just
have
to
start
and
do
it
so
my
question
would
be
or
whether
it
is
whether
there's
any
any
recommendation
to
start
codifying
this.
This
basically
coming,
on
the
one
hand,
from
the
definition
of
the
cnf
and,
on
the
other
end
from
codifying
how
to
come
with
best
practice
and
probably
we'll
end
up.
G
Meeting
in
the
middle,
without
chopping
off
our
respective
ads
too
much
yeah,
I
I
think
I
mean
taylor
put
something
up
which
I
I
did
like
the
definition
of
audiences,
which
is
context,
and
we
definitely
want
to
get
that
context
written
down,
because
best
practices
relate
to
context.
You
can't
have
a
best
practice
if
you
don't
know
what
it's
a
best
practice
for,
so
we
we
have
to
approach
this
from
both
directions.
E
Best
practices,
we
recommend
these
ones
right
now,
so
so
effectively,
three
tracks,
one
is
the
the
context
behind
the.
D
G
As
far
as
where
to
start
or
where
to
focus,
my
view
is
wherever
you
have
wherever
you're
reading
something
and
it
seems
to
affect
you
is
probably
or
whatever
interesting,
so
we
don't
have
to
stop
start
with
any
specific
ones.
I
some
of
these,
like
this
actors,
is
gonna
affect
everybody,
but
so
please
at
least
review
it,
but
talking
about
what
a
cnf
is,
but
maybe
we
should
start
with
what
a
cnf
does
before
we
talk
about
how
it
looks
like
how
it's
supposed
to
behave.
G
What
qualifies
as
a
cnf
in
the
end,
without
putting
in
a
definition
for
for
the
world,
but
what
qualifies
as
a
cnf
in
our
view-
and
maybe
we
can-
we
can
start
from
that
because,
once
you
know
what
it's
supposed
to
do,
you
can
start
working
towards
how
I
think
that
was
christian
bill
and
I
agree
like
I
think
that
ties
into
the
the
the
requirements
thing
right
like
what
do
we
need
is
like
not
just
what
does
a
cnf
do,
but
what.
D
E
What
I
don't
want
to
hear
is
that
a
cnf
is
a
vnf
that
follows
cloud
native
principles
like,
and
I've
heard
that
you
know
spoken
as
canon
more
times
than
I
can
count,
but,
like
you
know,
christian
hit
the
nail
on
the
head,
like
you
know,
we
keep
coming
like.
Why
are
we
doing
this,
and
I
mean
we
all
know
what
we
have
to
make
this
cloud
native
transformation.
So,
like
we
get
into
the
whole
motivation
discussions,
I
mean
it's
coming.
Vendors
are
making
it
this
way.
Service
providers
are
deploying
it.
E
This
way
like
it's
just
whether
it's
a
chicken
or
any
scenario
what's
happening
so
like
we
need
to
start
identifying
like
our
our
requirements
on
like
how
and
why
we're
doing
stuff
right
like
what
is
this
cnf
supposed
to
provide
us?
You
know
from
a
developer
standpoint
from
an
operator
standpoint,
all
those
people
that
are
in
the
actors
page
like
we
all
collectively
are
saying
this
is
the
path
we're
going.
D
G
B
So
how
do
we
qualify
that
I
don't
know,
but
I'm
just
playing
devil's
advocate?
Well,
that's
why
I
asked
the
question-
and
I
was
just
reading
through
the
monster
discussion
that
that
and
shane
were
having
on
the
subject
of
you
know
the
fantasy
that
I
I
think
we
all
subscribe
to.
We
all
wish
we
were
there
is
I
get
my
cnf
from
whoever's
supplying
it,
whether
it's
a
vendor
or
it's
another
team
in
my
organization
it
really
doesn't
matter.
The
point
is
it's
an
independent
unit?
B
That's
not
me,
and
I
want
to
get
it
on
my
network
in
24
hours.
How
am
I
going
to
do
that?
The
practical
problem
that
you've
got
there
is
that
you're
integrating
it
in
a
wider
system,
and
you
would
like
to
make
sure
effectively
all
of
its
interfaces
work.
The
way
they're
supposed
to
do
all
of
those
touch
points
actually
meet
with
the
expectations
of
the
thing,
that's
consuming
them
and
then
you'd
like
to
put
it
through
its
paces
as
much
as
you
possibly
can.
B
So
it's
got
to
effectively
be
easy
to
test,
which
means
it's
got
to
be
in
turn
easy
to
deploy
easy
to
upgrade
this
sort
of
thing.
It
seems
to
me
that
the
the
way
to
determine
what
requirements
exist
is
to
actually
put
this
in
the
context
of
problems
like
that.
This
is
the
thing
that
I
would
very
much
like
to
do,
and
I'm
assuming
that,
even
if
I
don't
get
to
you,
know
a
24-hour
deployment
cycle
or
a
two-minute
deployment.
E
Cycle,
whatever
it
happens
to
be
then
at
least
traveling.
That
journey
will
give
me
something
that
continually
gets
better.
So
what
is
going
to
help
me
on
that
journey,
and
then
you
get
to
a
definition
of
what
I'm
looking
for
from
a
cnf
and
then
you
get
to
best
practices
in
the
cnn,
but
doesn't
that
differ
from
one
type
of
application
to
another
I
mean
in
the
end.
Why
would
you
want
to
put
a
minor
change
in
your
network
or
a
new
application?
Your
network
in
24
hours,
maybe
yeah
fine,
but
24
hours,
one.
E
H
H
If
I
want
a
new
application
that
I
have
no
idea
what
it
is-
and
I
want
to
put
it
in
my
network
in
24
hours,
then
I
do
have
a
problem.
But
if
I
want
to
patch
something
there's
two
different
workflows
here,
one
is
patching
so
rolling
out
an
upgrade
in
24
hours,
which
is
fine.
I
think
we're
beyond
that
and
we
should
target
for
a
lot
less,
but
fine
with
the
20..
They
don't
get
tied
up
with
the
number.
The
number
was
just
yeah
yeah,
I'm
just
the
important.
H
The
important
thing
about
the
number
is
it's
less
than
three
months,
which
is
not
an
unusual
length
of
time
for
a
physical
device,
so
I'm
just
picking
an
umbrella
in
it
here.
That's
all,
of
course,
the
what
I'm
the
point
I'm
making
is
the
there's
two
different
workflows.
One
is
patching,
which
is
driven
by
some
considerations
like
security,
like
compliance
like
bug,
fixes
and
the
other
is
new
deployments.
H
So
when
you
do
have
a
patcher
you're
kind
of
assuming
that
you
have
that
application
in
production
already
and
you're
figuring
out
qualification
mechanisms
and
upgrade
mechanisms.
That
should
pretty
much
be
allowing
you
to
do
this
in
line
in
place
without
any
sort
of
service
interruption
or
minor
service
interruptions,
and
the
questions
are
around.
How
do
I
qualify
this
against
my
previous
baseline?
What
do
I
need
to
test
and
what
ensures
that
I?
H
I
can
move
forward
in
the
steps
and
what
are
the
checks
between
various
canaries
that
I'm
going
to
do
until
I
reach
a
full
full
out
rollout
and
then,
if.
D
H
Some
reason
that
fails
somewhere
in
the
intermediate
steps:
how
do
I
roll
back
and
how
do
I
ensure
that
everything
rolls
back
cleanly
now
when
you're
talking
about
a
new
application?
That's
a
completely
different
workflow,
because
you
have
to
understand
how
that
application
integrates
into
the
wider
ecosystem
and
that
study
and
the
definition
of
those
I
was
just
looking
over
one
of
the
discussions
and
one
of
those
is
around
dependencies
dependencies.
H
You
don't
have
to
worry
about
them
or
you
have
to
worry
about
them
in
a
different
way
when
you
handle
an
upgrade,
whereas
you
have
to
worry
about
them
in
a
completely
different
way.
You,
when
you
have
to
instantiate
something
new
in
one
place,
you
want
to
ensure
that
you
act
on
the
components
in
accordance
with
that
dependency,
so
that
you
don't
break
the
dependency
chain,
and
you
end
up
at
some
point
causing
a
service
outage
in
the
other.
You
want
to
identify
what
are
the
dependencies
who's
going
to?
H
So
the
two
workflows
are,
in
my
mind
at
least,
are
radically
different.
I
don't
know
whether
they're
radically
different,
because
you've
got
to
be
at
the
end
of
the
first,
with
the
workflow
you're
talking
about
when
you've
eventually
worked
out
how
to
deploy
it.
For
the
first
time,
you've
got
to
be
certain
that
you're
ready
for
that.
Second
workflow,
that
the
the
the
short
duration
upgrade.
Of
course
you
you've
got
to
you
know
it's
not
just
about
getting
the
application
running
in
your
network.
H
It's
about
understanding
that
there's
going
to
be
another
copy
of
this
application
turns
up.
You
know
next
wednesday,
and
I'm
going
to
want
that
in
my
network
as
well.
So
at
the
end
of
the
first
process,
you're
going
to
have
to
be
prepared
to
start
from
the
second,
so
it's
not
perhaps
I'm
we're
not
comparing
light
with
like
they
will
absolutely
be
different,
but
the
first
one
has
to
end
at
a
point
where
you're
prepared
to
start
the
second
one
at
any
moment.
So,
okay
yeah.
H
We
want
to
tackle
both
at
this
stage
or
should
we
pick
one
like?
Let's
pick
the
sip
into
it?
Let's
pick
the
one
that
we
start
with,
so
if
we
model
that
and
understand
it,
and
then
we
move
on
to
the
second
one,
which
obviously
has
slightly
different
behaviors
and
maybe
we'll
understand
something
else
after
we
modeled
the
first
one.
That
was
the
original
point
yeah.
H
No,
I
see
where
he
is
airflow,
or
should
we
look
at
the
instantiation
workflow
first,
my
rather
than
saying
here
is
a
specific
workflow
and
you
must
follow
it.
I
think
what
you're
talking
about
the
needs
behind
those
workflows
is
more
important
because
we're
not
saying
we're
going
to
copy
over.
What's
there
and
add
to
it,
what
we're
looking
at
is,
if
you
have
something
like
we
need
to
get
a
security
patch
out,
then
what
are
the
best
practices
so
on
the
life
cycle,
management
or.
B
You
already
have
something
out
a
application
running.
You
need
to
get
a
security
patch
out.
So
what
are
best
practices
that
help
with
that
that
one
goal.
So
that's
one
thing
that
you
want.
You
have
something
else
where
you
say
a
misbehaving
app
is
running
and
we
don't
know
what
the
problem
is.
So
what
are
best
practices
that
help
you
observe
and
get
information
about
that
application,
best
practices
on
kubernetes,
so
yeah?
Those
are
the
underlying
concerns,
so
whatever
level
you're
at
a
new
deployment,
a
running
deployment,
a
rollback
all
of
these
things.
B
What
are
those
underlying
needs?
And
now
we
can
start
looking
at
what
are
best
practices
that
already
exist
in
kubernetes
that
are
applicable
or
ones
that
we
should
invent
because
we
need
them.
But
all
I
would
say
is
there
isn't
necessarily
anything
stopping
us
from
writing
both
of
those
together,
but
but
what
you're
saying
is
that
what
I
write
in
one
is
necessarily
going
to
have
some
effect
on
the
other.
I
don't
think
that
stops
us
making
the
attempt
simultaneously.
B
We
just
have
to
understand
that
the
the
first
try
at
this
you
know
there's
going
to
be
a
revision
process.
It's
going
to
take
some
time
to
get
to
a
place
that
we
like,
but
we
could
write
both
of
those
up
and
it's
what
I
was
saying
earlier.
This
is
these
things
individually.
These
are
not
best
practice.
These
are
context
effectively.
These
are
the
things
we
would
like
to
do.
This
is
the
context
that
will
determine
what
best
practices
matter
to
us
so
so
looks
like
we
seem
to
be
going
all
over.
B
I
thought
jeff
started
the
discussion
with
the
c
and
f.
What
is
the
cnf,
and
now
we
are.
We
are
going
into
all
kind
of
workflows
and
and
the
best
practices
for
for
workflows
and
whatnot
and
and
we
completely
drifted
away
from
what
a
cnf
is
and
and
the
the
point
which
I
wanted
to
make
for
a
while
ago.
As
soon
as
jeff
started
discussing
that
was
taylor
during
the
tug
time,
then
do
you
define
or
did
didn't?
B
We
define
those
cnfs
where
we
call
them
bronze,
silver
and
gold
and
whatnot,
and
there
was
an
attempt
made
that
where
what
were
these
cnfs
are,
what
do
they
look
like?
What
do
they
have?
At
least
at
least
an
attempt
was
made
there.
So
where
are
we
not
picking
up
from
there?
Why
we're
trying
to
reinvent
all
over
again?
B
There
was
I
mean
so
people
still
will
I
mean
I.
I
sit
into
a
lot
of
meetings
and
I
hear
people
argue
about
it
all
the
times
that
guys
vnfs
are
not
going
away.
They
are
here
they're,
going
to
stay
here,
they're
going
to
stay
here
for
a
very
long
time
and
and
the
vendors
need
to
see
an
incentive
to
throw
away
their
vnf
implementations
and
and
start
getting
into
cnf
implementation
with
not
even
knowing
what
a
cnf
implementation
looks
like.
G
40
people
or
30
people,
whoever
we
have
on
the
call.
If
I
asked
you
know
that
what
is
the
cloud
native
and
and
we're
not
going
to
get
one
answer,
we're
going
to
get
at
least
20
answers
so
and
I
do
that
all
the
times.
So
why
are
we?
Why
are
we
not
starting
with
there,
and
I
thought
tug
was
doing
that
drugs
started
to
do
that,
especially
when
they
got
into
gold
cnfs,
you
know.
So
there
were
bronze,
there
were
silvers,
but
the
gold
cnf
gold
cnf
is
pretty
darn
close.
B
B
We
want
to
be
able
to
achieve
this
and
by
end
of
q2
like
robbie,
is
on
this
call
who
was
leading
cnpt
and
the
only
reason
we
made
tremendous
progress.
There
was
that
he
will
step
up
and
he
will
start
setting
up
the
goals.
He
will
say:
okay,
guys,
let's
define
this
release,
let's
define
this
content,
let's
go
with
this
and
and
work
with
that.
B
So
so
here
my
suggestion
is:
we
should
take
some
kind
of
a
similar
approach
right
and-
and
let's
start
writing
it
down-
let's
start
defining
it,
but
then
then
we
take
it
as
as
it
comes,
rather
than
because
everybody
seems
to
be
wishy-washy,
everybody
seems
to
be
going
all
over
depending
upon
what
our
personal
preferences
are.
Whatever
backgrounds
are,
where
we
come
from
right,
so
so
there's
a
lot
of
bias
based
upon
what
what
we
have
been
exposed
to
what
we've
been
using
to.
B
But
but
there
are
certain
things
which
are
in
front
of
us,
so
whether
we
pick
what
is
available
and
then
start
to
work
from
there
and
my
suggestion
is,
there
are
write-ups
on
on
what
what
gold
cnfs
are.
Let's.
C
C
Jeffrey's
posted
something
there.
That's
now
that's
what's
used
in
the
text,
so
that's
kind
of
the
starting
point
for
all
of
this:
the
principles
to
go
with
what
you
were
saying
as
before.
C
Yes,
there's
a
lot
of
people,
that'll
say
a
lot
of
different
things,
but
if
you
go
and
look
at
the
I'll
say
the
experts
in
the
field,
whether
you're
saying
specifically
cloud
native,
whether
you're
going
into
kubernetes
usage,
whether
you're
going
to
stuff
that
builds
into
cloud
native,
a
devops
and
wherever
you
want
to
look,
there's
a
lot
of
content
that
go
right
into
what
the
principles
are
about.
It
happens
that
cncf
doesn't
have
those
expanded
out
directly
in
their
definition,
but
it
doesn't
mean
that
the
experts
that
put
forward
these
haven't
said
a
lot.
C
So
this
is
a
good
place
to
start.
If
we
want
to
look
at
some
of
these
things,
but
I
don't
think
jeffrey
was
specifically
looking
to
say:
do
we
have
any
idea,
it
was
more
of.
Are
the
best
practices
that
we're
putting
forward
going
to
be
applicable?
Are
we
going
to
cause
problems?
So
it's
it's
a
more
specific
thing
and
then,
as
far.
A
Use
kubernetes
and
they
they
have.
Why
are
we
doing
this?
We
want
to
lower
at
opex,
primarily,
I
would
say,
but
it
probably
affects
capex.
We
were
talking
about
life
cycle
management,
so.
C
How
are
we
going
to
lower
the
opex
cost,
whether
that's
reducing
risk,
whether
that's
making
it
easy
to
manage
changes
on
the
network,
because
you
push
more
stuff
out
to
the
infrastructure
that
already
is
handling
some
of
those
things.
So,
if
you're
building
a
an
application
that
you're
selling
to
sp,
you
know
that
you're
focused
on
the
part
that
matters
the
most,
that
you
have
the
expertise
on
and
you're
not
having
to
do
additional
work
outside.
C
So
it's
it's
all
around
those
same
things
as
far
as
the
reasons,
but
the
goal
that
shared
goal
of
how
to
best
utilize
kubernetes
the
framework,
the
community.
So
outside
of
you
know
just
our
group.
How
do
we
bring
more
and
more
in
that
already
have
the
knowledge
on
running
these
applications?
Financial.
E
E
E
E
I
think
it's
right
there
in
what
jeff
put.
C
So
yeah,
I
think,
to
both
christian
and
anne
the
what
the
reason
why
we're
bringing
up
cnf's
a
what
is
a
cnf
or
what
are
the
goals
of
cnf
for
all
of
these
things
or
because
we
need
context
the
same
same
as
everything
else
we're
talking
about
during
this
call
for
why
a
best
practice
would
be
put
forward
it
at
all.
C
D
G
We
have
all
of
that
so
that'll
be
something
that
I'd
like
to
put
on
at
least
my
plate,
and
if
anyone
wants
help
to
look
at
and
then
we
can
do
the
same
thing
from
the
cnf
working
group
where
we
go
here
is
what
we're
referencing,
along
with
what
jeff
is
saying,
but
what
we
probably
don't
have
anywhere
else
is
some
of
the
context
that
jeff
was
worried
about
where
we
put
a
best
practice
forward
and
it
doesn't
apply
to
a
cnf,
that's
very
common,
so
we
have
something
out
there
we
put
the
best
practice.
G
It
only
causes
problems
if
you
use
that
best
practice
on
the
cnf.
So
how
do
we
communicate
that
that
it's
not
either
not
applicable
to
this
one?
You
shouldn't
use
it
wherever.
However,
we
deal
with
that,
that's
I
believe
jeff.
The
main
thing
that
you're
wanting
to
put
forward
on
this
is
it's
you.
You
got
it
spot
on
so.
E
I
just
confirmed
my
own
fears.
I
did
not
speak
with
enough
specificity
with
my
initial
discussion
thing
and
so
then
lots
of
room
for
interpretation
which
muck
things
up
you're
dead
on
taylor
is
like
would
a
cnf,
that's
specifically
targeting
layer,
2
and
potentially,
you
know
interacting.
G
At
like
the
nick
layer,
gonna
have
the
same
best
practices
as
maybe
one
operating
at
layer.
Three,
and
is
you
know,
looking
at
route
tables,
etc.
I
don't
know
the
answer
to
that
right
now,
just
hypothetical
right!
G
So
like
it's
exactly
what
you
said
is
you
know,
do
we
expand
upon
it
and
ensure
that
we
we
just
give
like
the
proper
context
for
when
we
say
a
best
practice
of
like
this
applies
to
this
type
of
workload,
because
it's
going
to
give
you
the
optimal
results
based
on
what
this
specific
you
know,
container
function
whatever
it
is
trying
to
accomplish,
and
then,
if
we
need
to
expand
definition,
we
can
you
know
if
we
need
to
contract
it
whatever,
but
like
the
big
thing
is,
if
I
just
say
no,
no
root,
you
know
privilege
in
any
containers.
G
B
It's
like
here's,
a
reference
architecture,
you
know,
here's
a
white
paper
like
my
hope
is,
is
when
I
come
from
this
group.
I
have
things
in
my
toolkit
that
I
can
actually
go,
and
you
know
pun
fully
intended
put
into
practice
versus
you
know
just
abstract
concepts
that
I'm
like.
Okay,
you
know
these
are
great
guidelines
that
I'm
going
to
follow
like
follow
at
like
a
broad.
G
B
G
I
E
That
you're,
looking
for,
like
cnf's
container,
should
run
on
privileged
absolutely
right
and
once
again,
though,
it
has
to
have
the
context,
because
ian's
concerns
are
valid.
I'm
going
to
put
this
in
an
rfp,
you
know:
are
these
containers
unprivileged
or
are
they
going
to
try
to
mess
with
my
my
infrastructure?
E
Are
they
going
to
try
to
talk
to
the
kernel
and
do
things
that
I
might
not
want
to
do?
If
we
have
the
context,
then
I
would
try
to
tailor
that
rfp
to
make
sure
that
once
again
we're
following
a
lease
privilege
model
versus
a
no
privilege
model,
but
you
know
this
is
something
I
can
test
too
like
I
can
go
in
and
then
I
can
try
to
like
go
into
one
of
these
containers
and
try
to
execute
system
commands
that
I
shouldn't
be
able
to
do.
I
can
test
this.
E
G
G
Another
thing
again
that
you
can,
we
may
be
able
to
steal
from
my
past
life
is
when
we
were
doing
compliance
in
those
days,
then
there
were
a
set
of
rules
largely
around
right
software
that
you
know
doesn't
break
in
horrendous
ways
and
kill
people,
and
there
were
a
set
of
exceptions.
You
could
because
no.
G
E
Formal
process
for
writing
the
exception
down
explaining
the
exception
and
supplying
it
along
with
the
application.
You
were
shipping
and
yeah.
It's
a
get
out
clause.
It
basically
says
I
can
be
compliant
without
being
compliant,
but
on
the
other
hand,
if
we
had
a
best
practice
along
the
lines
of
this
is
how
you
document
why
you're
not
following
a
rule,
in
certain
circumstances,
how
to
identify
that
how
to
demonstrate
it's
constrained
and
so
on
and
so
forth,
and
that
also
might
work
for
us.
E
Because
christian
right
there
on
the
screen,
put
in
an
example
of
a
perfect
idea
where,
like,
if
I'm
you
know-
and
this
gets
into
the
whole
other
best
practices
on
the
dev
side
might
come
out
of
like
do
I
compartmentalize
so
there's
not
one
giant
homunculus
container.
That
has
all
these
things,
because
it's
doing
like
layers,
one
and
two
stuff,
it's
doing
layer
three
stuff,
but
you
know
he
puts
like
thing
like.
If
we
decide
we're
gonna
go
down
an
srov
path,
I
spin
up
a
new
container.
E
It's
going
to
have,
to
you,
know,
be
able
to
interface
with
the
system
and
pull
that
vfid
into
it,
etc.
Right
so
that's
christian,
put
like
a
great
example,
the
types
of
stuff
I'm
just
curious
and
like
99
of
the
time
it's
going
to
be
applicable,
but
here's
an
example
of
where
it's
not
so.
We
document
it
as
an
exception
and
we
provide
the
context
of
what
it
is
a
best
practice.
E
Of
more,
it
was
started
from
a
thread
in
slack,
but
one
of
the
biggest
issues
I
have
when
looking
at
the
cnf
or
vnf
is
what
are
his
dependencies.
Who
does?
Who
needs
to
talk
to
this
cnf.
G
D
G
G
D
G
Two
cnfs
or
something
like
that.
My
idea
here
is
more
around
relationships,
not
interfaces
to
the
system,
but
when
you
have
two
three
five
cnfs
on
the
same
kubernetes
cluster:
how
do
they
do
they
know
about
each
other?
How
can
we
do
maintenance
on
one
while
not
impacting
the
other?
How
can
we
suspend
one's
operations
or
how
can
we,
let's
take
an
example.
G
Real-Life
world,
if
my
upstream
link
is
down,
I
want
to
ensure
that
I
put
the
ports
on
the
switch
down
so
that
I
immediately
take
the
entire
data.
E
Path
offline,
so
that
my
applications
can
fail
over
to
the
active
one.
Can
we
do
something
similar
for
cnfs?
Can
we
inform
one
that
its
dependency
went
away
so
that
shuts
down
and
commits
shifts
over
to
its
standby
christian?
Are
you
talking
about
a
I'm
gonna
call
it
a
product.
A
vendor
sends
a
specific
type.
G
Of
application
to
handle
things,
it
may
have
many
different
components
and
parts,
and
they
all
need
to
work
together.
It's
more
about
multi-vendor.
Let's
say
I
have
one
component
from
one
vendor
another
component
from
another
vendor
and
the
upstream
component
needs
to
inform
the
downstream
one
all
right
do
that
in
a
generic
way,
so
that,
yes,
I
want
to
swap
vendors
from
both
upstream
and
downstream,
and
not
have
to
worry
about
the
fact
that
I'm
going
to
need
this
interdependency
to
work
and
those
vendors
need
to
be
certified.
This
comes
down
to.
Can
I.
I
Do
my
qualification
in
24
hours
or
not?
If
I
know
vendors
respect
that
interface,
then
it's
easier.
So
if
you
yeah
and
you've
hit
the
nail
on
the
head
here,
it's
not
about
the
two
pieces
of
code.
It's
about.
Do
they
respect
the
interface.
So
you
would
you
know
I'll
use
bgp
as
a
fairly
traditional
example.
Here
in
theory,
if
not
in
practice,
every
bgp
speaker,
you
can
pull
off
the
shelf
will
talk
to
any
other
bgp
speaker.
You
can
pull
off
the
shelf.
A
I
I
I
I
was
using
it
as
an
example.
I
I
wasn't
absolutely
I
I
mean
I
know
what
you're
thinking
that
you
could
play
with
roots.
That's
not
my
point.
That's
not
the
point
I
was
making.
I
was
saying
that
bgp
is
a
defined
protocol
so,
rather
than
defining
anything
else,
what
I'm
actually
defining
is
the
place
where
these
two
potentially
huge
pieces
of
code
touch
and
because
they
touch
in
a
very
small
area.
You
know
the
the
protocol
that
is
bgp.
I
Then
you
can
document
the
protocol
and
you
can
be
almost
certain
before
you've
ever
brought
them
together
on
the
same
system
that
they're
going
to
work
together
because
they
both
respect
bgp,
and
you
can
demonstrate
that
I
can
do
this
with
apis
the
same
way.
Theoretically,
I'm
struggling
to
think
of
a
fine
example
of
an
api,
but
the
idea
would
be.
There
is
an
api
definition
for
a.
B
All
right,
let
me
take
a
weird
example,
but
it
will
do
for
now
right,
kron.
There
are
many
implementations
of
cron
out
there,
but
I
don't
have
to
know
the
details
of
each
implementation
because
ultimately
they
respect
the
same
cli.
I
use
them
in
exactly
the
same
way
so,
regardless
of
which
quantum
crown
implementation
I
happen
to
be
running
on
my
box.
It
will
do
the
same
job
if
I
tell
it
to
do
the
same
thing.
B
So
all
I
have
to
document
is
how
I
use
it:
no,
not
what
it's
doing
behind
the
scenes,
and
so
theoretically,
if
I
write
script,
that
programs,
chrome
and
I
implement,
and
I
install
whichever
version
of
cron,
I
personally
favor
on
my
box.
I
know
these
things
are
95
likely
to
work
together
because
the
api
definition,
the
interface,
is
what
I've
written
down.
B
So
in
your
case,
you're
saying,
are
there
some
generic
interfaces?
I
know
interface
is
a
loaded
term
in
networking,
but
you
know
what
I'm
saying
here:
are
there
generic
interfaces?
I
could
write
down
where
specific
kinds
of
touch
point
could
be
documented.
I
had
in
mind
something
a
bit
more
id
side,
namely
juju
from
canonical,
which
has
providers
and
the
consumer's
kind
of
interface.
B
So
it's
a
declarative
way
of
saying:
myvnf
provides
load,
balancing
services
and
my
web
server
is
a
consumer
of
load
balancing
services.
If
I
type
those
two
together,
I
know
that
the
load
balancer
will
load
balance
traffic
coming
into
my
web
server.
A
perfect
example
of
this
of
a
proper
implementation
is
the
ingress
controller.
I
know
it's
crappy,
everyone
hates
it
and
I'm
streaming
and
wants
to
rewrite
the
ingress
interface,
but
it
actually
does
what
what
it's
supposed
to
it
says.
B
The
ingress
controller
provides
this
kind
of
service
and
I'm
the
consumer
of
the
ingress.
For
sure.
One
of
the
issues
of
the
ingress
controller
today
is.
I
cannot
tell,
from
the
ingress
controller,
to
the
back
end
that
the
ingress
controller
is
down,
so
the
back
end
has
no
way
of
knowing
it's
no
longer
a
signaling
traffic,
except
for
observing
the
fact
that
it's
no
longer
receiving
traffic.
B
But
it's
a
it's
going
along
those
lines
of
declarative
dependencies
where
I
have
one
component
offering
a
service
and
another
component
saying
I'm
going
to
consume
that
service
yeah,
it's
a
contract
between
the
two,
exactly
it's
a
contract,
that's
where
I
was
trying
to
get.
We
need
to
define
this
kind,
or
at
least
in
my
mind.
I
think
we
need
those
kind
of
contracts
and
as
a
community,
we
need
to
agree
on
those
kind
of
contracts,
so
they
can
be
honored
by
different
vendors
yeah.
B
I
think
there
are
a
few
other
really
boring
contracts
that
we
need
to
remember
as
we're
doing
this.
The
one
that
keeps
coming
up
with
me
with
my
lot
is
logging
right.
I
I
know
I
absolutely
am
100
certain
that,
whatever
application,
I
wrote,
whether
it's
a
cnf
or
anything
else,
it's
going
to
spew
logs
at
something
and
something's
going
to
want
to
pick
them
up.
There
needs
to
be
a
contract
between
the
two.
So
that
way
I
send
logs
and
the
way
it
receives
logs.
B
We
both
agree
on
how
that's
going
to
work,
but
it's
still
a
contract
yeah.
That's
that's
a
perfect
clever
example
of
logging
is
really
painful.
Today,
we
in
my
case
I
have
two
types
of
logs:
basically
bond
structures,
logs
and
json,
structured
logs
and
figuring
out,
which
goes
where
and
telling
a
log
collector.
This
is
json
structure.
This
is
not
easily
painful.
Today.
My
log
collector
really
needs
to
parse
line
by
line
figure
out
if
it's
proper
json
try
to
interpret
the
json.
B
A
So
just
a
question:
would
it
make
sense
to
start
thinking
about
the
table
of
contents
that
need
to
be
created
for
the
artifacts,
regenerating.
A
A
So
the
thing
that
we
have
right
now
is
these
proposal
like
definitions,
and
so
this
is
similar
to
like
a
kubernetes
cup
where,
like
each
one,
would
define
like
a
best
practice,
and
so
we
were
just
thinking
of
serially
numbering
them.
But
if
you
think
there's
like
groupings
or
something
else
that
we
could
have
feel
free
to
open
a
pull
request,
robbie
was
there
a
specific
idea
that
you
had?
A
I
mean
I
was
thinking
like
to
work
backward
from
the
delivery
that
I
would
like
to
make
now,
if
we
say
we're,
gonna
release
something
as
part
of
the
outcome
of
this
working
group.
What
does
that
look
like?
Is
there
a
document
with
a
certain
structure,
different
sections,
and
if
we
say
okay,
if
this
is
the
overall.
E
Definition
of
what
we're
going
to
deliver,
I
think
going
back
to
this
question.
We
had
in
the
slack
channel
and
last
time
call
we
decided
to
look
at
the
guidelines
and
best
practices
for
the
cnf
developer
himself.
I
think
if
we
just
focus
on
that
and
think
about
what
would
the
content
be?
Look
like
and
start
to
put
some
real
content
in.
We
will
be
able
to
identify
the
relationship
with
other
parts
of
the
platform
or
trying
to
think
about
what
other
areas
we
need
to
work
on
next.
E
E
If
we
create
that
structure
and
document
structure
with
the
different
chapters
sections
whatever
it
is,
then
people
can
work
in
particular
section
particular
area,
even
if
they
can
have
an
off
call
or
something
that
for
those
who
want
to
sit
to
work
more
into
the
technicality
of
that
part,
it
would
be
more
like
tangible
outcome
that
we
can
lead
to
robbie.
That's
great.
We
didn't
go
into
all
of
that
earlier.
E
I
guess
when
we're
talking
about
structure,
what's
next
beyond
the
process
to
get
to
a
list
of
best
practices,
but
what
you're
saying
is
is
needed,
so
if
we
determine
a
set
of
best
practices
that
are
helping
to
most
efficiently
use
kubernetes
like
what,
where
is
that?
What
does
that
mean?
So
one
part
is
what
bill
is
saying
is
similar
to
keps,
so
this
enhancement
proposal,
but
the
other
part
may
be
more
similar
to
the
kubernetes
conformance
program.
E
So
if
you
go
and
look
at
any
new
release
where
they
say
here
is
the
version
of
kubernetes
and
what
tests
are
required
for
conformance,
it's
not
only
tests,
but
you
actually
have
the
test
and
why
they
were
there.
So
why
is
that
feature
part
of
kubernetes?
That's
not
immediately
apparent.
If
you
just
look
at
the
test,
you'll
have
to
dig
in,
but
that's
a
similar
thing
here.
E
So
if
we
end
up
with
a
set
of
best
practices
that
you
can
go
and
look
at
in
this
folder,
we'll
probably
have
something
similar
to
what
the
kubernetes
conformance,
which
is
a
large
document
which
lists
all
of
the
tests
that
are
required.
And
then
you
can
click
through
and
go
look
at
what
those
features
are
for
us.
It's
probably
going
to
be
here's
a
list
of
best
practices
in
a
document
and
some
maybe
a
subset
of
information.
E
So
you
can
quickly
see
here
are
the
ones
that
we're
recommending
that
people
use
and
the
audience
and
and
just
a
small
blurb
about
why
it's
good
click
here
to
go
read
in
details
about
this
best
practice.
That
would
be
similar
in
my
mind,
also
to
12
factor
apps.
So
now
we're
just
helping
people
do
better.
But
beyond
that,
how
are
we
trying
to
beyond
a
document
like
that
which
I
do
think
is
good
12
factor?
E
If
you
go
look
at
whether
you're
looking
at
12
factor,
you
have
a
list,
you
can
go
dive
in
deeper
and
so
on
beyond.
That
is
the
test
suite,
so
the
test
suite
is
currently
developing
and
working
on
based
on
feedback.
It's
already
getting
so
talking
to
vendors
talking
to
kubernetes
folks,
looking
at
stuff.
That
seems
like
good
things
to
test,
but
one
of
the
things
it'll
do
similar
to
kubernetes.
So
kubernetes
is
writing
tests
all
the
time
and
then
eventually
they
come
out
with
the
best
practice
or
and
not
a
best
practice.
E
E
E
So
the
test
suite
is
primarily
to
allow
cnf
developers
or
we'd,
say
vendors
to
go
and
run
the
test
suite
and
see
how
well
they're
doing
on
these
best
practices
that
they
think
are
also
good,
hopefully
so
that
they
can
improve.
Maybe
it's
about
storage
data
or
how
you
store
data
in
a
cloud-native
way,
but
those
will
be
working
hand
in
hand
as
a
result
of
the
best.
E
Yeah,
I'm
happy
to
have
a
look
at
that
yeah
sure
okay,
that'd
be
great
and
I'd
love
to
have
that
discussion
when
you're
ready
to
have
it.
I
think
other
people
would,
I
think,
welcome
the
structure
in
it
too.
In
the
meantime,
it'd
be
great
to
move
forwards.
Our
discussions
in
the
discussion
board
around
the
different
best
practices
that
have
been
pro
so
far
on
the
definition
of
a
cncf
of
a
cnf.
E
I
know
we're
at
time
and
just
so
people
know
we
are
having
one
meeting
and
then
we're
skipping
the
next
two
weeks
and
starting
again
not
on
the
fourth,
because
I'm
assuming
everybody's
just
going
to
be
back
into
the
office,
but
our
next
meeting
after
that
will
be
on
the
11th.
So
thanks
everyone
for
your
time
today.
I
really
appreciate
it.