►
From YouTube: CNCF CNF WG Meeting - 2022-01-24
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
Yeah
we
can
hear
you,
oh
good,
that's
good
to
hear
we
seem
a
bit
thin
on
the
ground,
but
hello.
Everybody
who's
actually
turned
up
nice
to
see
you
all
again.
A
There
we
go
apparently
we're
all
doing
at
the
same
time
right
yeah.
So
let
me
just
get
through
the
agenda
as
we
have
it
right,
so
we
have
a
set
of
upcoming
events,
which
you've,
probably
all
seen
already
at
this
point,
so
I'll
just
recap
very
quickly.
The
european
version
of
kubecon
is
due
in
may
I
don't
know
where
we
stand
with
the
call
for
papers,
but
I
would
imagine
it's
ended
at
this
point.
A
I
will
go
and
do
my
research
after
this
and
add
the
those
deadlines
in
the
european
open
source
summit
in
september
and
kubecon
n
a
in
october
usual
practice
applies
if
you've
got
anything
at
any
of
those
events
that
you're
putting
in
or
that
you
would
like
to
make
people
aware
of
once
the
schedules
are
announced
then
do
tell
us
or
add
them
yourself
to
the
meeting
minutes
so
that
everybody
knows
what's
coming
up
and
what's
worth
doing,
oh,
we
do
have
coffee
papers
a
little
there
right.
A
Yes,
so
the
cloud
native
telco
day
there
at
the
kubecon
eu
so
if
you've
got
any
papers
to
put
in
before
february.
So
that's
about
what
four
weeks
left
at
this
point,
then
we
will
check
the
pull
requests
and
see
what
we
have
in
the
way
of
call
requests.
A
Because
I'm
running
the
meeting
and
it's
my
pull
request
will
open
mine
first,
so
the
idea
of
this
was
basically
it's
a
how
to
do
the
paperwork
side
of
things.
A
I
wrote
this
up
with
the
specific
idea.
I
see
we
have
no
comments
to
speak
of.
I
wrote
this
up
with
the
specific
idea
of
not
saying
here
is
the
best
practice,
but
here
is
how
you
document
the
best
practices
you
are
compliant
or
non-compliant
with,
because
the
concept
I
had
was
that
if
you
want
to
be
compliant
with
all
the
best
practices,
there
may
be
solid
technical
reasons.
Why
your
cnf
your
platform,
your
system,
can't
be
compliant
for
some
way.
A
Maybe
you
have
a
better
way
of
doing
it
or
just
simply
a
different
way
of
doing
it.
Maybe
it's
something
you
haven't
gotten
to
yet,
if
you
are,
for
instance,
in
my
position,
supplying
a
cnf
to
somebody
and
they're
giving
consideration
as
to
whether
to
run
it,
it
may
be
acceptable
that
you
aren't
compliant
with
best
practices,
but
it's
important
that
you
have
a
record
of
what
you
have
and
have
not
done
so
that
they
can
review
it
and
see
what
they've
done.
A
A
So
again
it's
more
and
the
nature
of
paperwork
around
documentation
than
it
is
about.
You
will
do
things
in
you
will
build
your
your
application
or
your
system
in
a
certain
way.
I
see
it's
got
no
reviews.
Yet
I
encourage
you
to
have
a
go
at
the
reviews.
Skim
it
for
yourself
make
sure
you
get
what
I've
written.
What
I
was
trying
to
get
at
I've
tried
to
keep
it
short.
I
wasn't
trying
to
make
anything
particularly
complex.
A
Just
simply
have
a
a
means
of
supplying
that
record
so
that
everybody
can
review
it
on
their
own
part
as
they're
trying
to
build
one
of
these
cnfs
or
platforms
or
whatever
into
a
system.
B
Damn
it
ian
this,
this
is
oliver.
I
I
I
generally
understood
what
you
were
saying.
I
guess
I
wasn't
really
clear,
though,
in
terms
of
where,
where
is
it
well
I'll
tell
you
what
I
haven't
read
it
so
I
guess
I
was
trying
to
understand
how
how
is
this
to
be
used,
but
maybe
I
I
will
get
that
after
reading
it
so.
A
A
The
conceptually
my
point
was
that
for
an
a
component
in
a
system
like
a
cnf
or
your
kubernetes
platform
or
whatever,
then,
if
you,
for
whatever
reason,
can't
be
compliant
with
the
rules,
then
it's
better
that
you
write
it
down
and
make
that
abundantly
clear.
Then
you
say:
well,
you
obviously
can't
say
we
are
compliant
with
the
list
of
best
practices.
A
So
it's
better
that
you
document
how
well
you've
done
and
what
you've
missed
so
that
when
you
try-
and
you
know,
if
it's
an
open
source
project
when
somebody
tries
to
consume
it,
if
it's
a
closed-sourced
product,
then
when
somebody
tries
to
buy
it,
they
understand
what
they're
getting
into
and
similarly
at
the
system
level,
if
you're
at
a
telco
and
you're
trying
to
build
a
system,
then
when
your
auditors
come
along
and
say
what,
from
the
best
practices
have
you
covered
and
not
covered,
then
again,
you're
not
trying
to
somehow
scrape
together
a
statement
of
compliance
from
components
that
simply
don't
comply,
but
instead
you're
actually
just
cutting
it
down
on
a
piece
of
paper
saying
this
is
how
well
or
badly
we've
managed.
A
You
know.
The
assumption
here
is
that
with
the
next
version
or
whatever
you've
got
some
updates
and
you
would,
you
would
improve
upon
that
compliance
and
while
you're
not
compliant,
then
you
might
have
mitigations
in
place.
So
if
you
can't,
for
instance,
make
or
use
a
cnf
that's
fully
compliant
with
all
of
the
security
best
practices,
then
you
might
put
other
security
practices
in
place
to
manage
that
non-compliance.
A
A
Okay,
thanks
for
that,
I'll
have
I'll,
definitely
have
a
look,
yeah,
probably
better
red
than
me,
trying
to
review
it
for
give
you
the
clues
from
memory.
Because,
again
I
wrote
this
before
christmas
and
it's
been
too
long
at
this
point,
but
it's
there
to
be
looked
at
thanks
right.
I
actually
haven't
read
this
one
either,
so
I'm
not
going
to
do
a
very
good
job
of
this
and
it
looks
like
nobody
else
has
for
that
matter.
A
Oh,
I
tell
a
lie:
olivier
yeah,
that
there's
one
or
two
reviews
in
there
yeah.
So
the
aim
here
was
to
describe
how
user
stories
of
stateful
cnfs
work,
particularly
things
that
have
to
live
beyond
the
life
of
a
piece
of
software.
A
You
know
if
the
software
is
upgraded,
rebooted
restarted,
then
the
data
that
needs
to
live
on
beyond
that
point
that
could
be
simply
configuration.
It
could
be
billing
records,
but
the
aim
was
to
document
best
practices
around
that
say
this
is
what
you
should
be
doing
with
that
kind
of
data.
This
is
the
best
way
of
storing
it
to
get
the
level
of
resiliency
that
you're
looking
for.
A
And
again,
I
can't
say
that
I've
had
it
look
through
it.
I
see
it's
relatively
brief,
so
I
should
have
a
look
through
it
again.
Anyone
any
thoughts
on
this
at
this
point
in
time.
A
Okay,
well,
usual
rules
apply
it's
there.
You
should
read
it.
You
should
put
your
review
comments
in
there.
I'm
sure
taylor
and
jeff
would
appreciate
it,
because
I
think
this
is
their
baby.
A
Right
this
one,
we
do
have
two
comments
on
this
as
well,
and
it's
also
incredibly
brief.
The
concept
of
this
one
is
it's
pretty
common
in
my
experience,
and
I
think
that
goes
for
jeff
as
well,
that
if
you're
running
a
cnf
or
any
network
function
in
a
telco
network,
then
you
generally
don't
hinge
your
ability
to
deliver
services
on
an
attachment
to
the
internet,
so
you're
not
necessarily
pulling
software
directly
down
from
the
internet.
A
You
aren't
about
to
go
to
the
internet
to
see
if
a
corporate
licensing
server
is
going
to
give
you
a
license
today
and
of
course
you
don't
really
want
to
be
connected
to
the
internet
and
certainly
on
the
management
side
of
things,
because
security
says
that
an
air-gapped
environment
is,
you
know
infinitely
more
secure
than
one
where
potentially
an
attacker
can
try
to
get
control
of
your
management
network
from
the
internet.
A
So
this
is
best
practices
revolving
around
that
level
of
disconnection.
If
you're
trying
to
put
software
into
the
network,
how
do
you
put
software
into
the
network
if
you're
trying
to
you
know,
share
licenses
with
applications
that
require
licenses
before
they'll?
Come
up?
How
do
you
get
those
licenses
to
the
relevant
pieces
of
software
when
an
internet
connection
is
not
feasible?
A
I
don't
know
how
far
this
has
gone
and
again
I
have
a
guilty
conscience.
This
week
I
haven't
looked
at
this
one
either,
but
I
know
that
was
the
concept
behind
it.
A
I
I
would
guess,
by
sort
of
simply
reading
the
high-level
description
that
this
was
effectively
an
attempt
to
get
people
to
think
on
the
subject
and
what
it
requires
is
not
just
comments,
but
actually
extension,
quite
a
bit
more
information
than
it
currently
contains.
So
I
imagine
you
all
have
an
interest
in
this.
It
looks
particularly
like
victor
already
has
shown
an
interest
in
this,
because
I
can
see
I
can
see
the
comments
in
there,
but
yeah
further
review
required.
A
So
please
do
again
all
have
a
look
at
this
and
see
how
how
you
want
to
improve
upon
it.
A
Okay
and
that
being
the
end
of
a
very
short
agenda
and
only
20
minutes
in
the
meeting,
then
you're
now
we're
up
for
discussion.
So
has
anyone
got
a
point
that
they
want
to
bring.
C
Hey
hello,
hey
hey
ian
good
morning,
I
had
a
pull
request
that
I
created
I
think
few
minutes
ago.
So
that's
basically
to
integrate
some
of
the
keyword
no
test
cases.
So
I
was
trying
to.
C
I
was
trying
to
integrate
the
kubernetes
tool
with
the
c
cnf
test
week.
I
created
a
pull
request,
but
do
you
not
see
that
here.
A
A
Yes
and
lucina
can
keep
me
honest
here,
but
I
believe
that
group
meets
on
thursday
mornings,
and
that
is
probably
a
moment
for
raising
it.
What
I
would
say-
and
I
think
we've
had
this
discussion
before-
is
if
kivano
can
be
a
solution
for
best
practices.
If
you
can
take
what
you're
trying
to
do
with
kivono
and
speak
about
it
in
the
abstract,
rather
than
using
the
tool
name,
then
that's
what
I
would
call
the
best
practice
so
you're
not
describing
run
this
caverno
command
run.
A
This
you
know
run
this
in
your
in
your
ci
or
whatever.
What
you're
doing
instead
is
you're
saying
that
this
is
a
problem
with
this
system,
and
you
want
mitigations
of
this
nature
in
place.
I
think
we
did
have
one
a
while
back,
which
basically
did
describe
some
of
the
ways
in
which
you
can
apply
security,
such
as
effectively
active
monitoring
of
a
system.
A
That's
running
to
make
sure
that
you
know
security,
red
flags
are
picked
up
early,
but
anything
that
you
consider
to
be
worthwhile
in
any
form,
including
you
know,
static
analysis
or
test
analysis
of
something
you
might
want
to
be
running
in
or,
alternatively,
monitoring
it
in
production.
If
you
can
bring
that
into
the
abstract
and
say
this
kind
of
monitoring
should
be
seen
in
the
in
a
running
system,
because
it's
an
obvious
thing
to
do
and
without
it
then
you're
at
serious
risk.
Then
that's
the
level
of
description
that
we're
looking
for
here.
C
C
Got
it
so
basically,
so
you
want
like
an
abstract
of
what
what
what
problem
that
particular
policy
or
tool
is
trying
to
bring
right.
That's
what
you
want
correct.
A
Yeah
so
you're
making
effectively
your
case
for
caverno
in
the
abstract,
you're
saying
that
and
there's
nothing
wrong
with
being
very
pointed
about
your
use
case.
But
you're
saying
in
the
abstract
here
is
a
problem
and
in
the
abstract
here
is
a
way
of
making
sure
that
problem
doesn't
cause
you
significant
distress
and
then
from
there
you
would
say:
kiverno
is
a
solution
to
that
problem,
and
for
these
reasons
this
is
a
thing
that
it
does,
and
this
is
how
it
helps
you.
A
I
mean
I
have
no
problems
with
recommending
specific
tools,
but
I
this
should
not
be.
You
know
if
somebody
creates
another
tool
in
the
future
which
is
tons
better,
for
whatever
reason
it
shouldn't
be
ruled
out,
because
we
picked
it
all
by
name.
But
aside
from
that,
I
mean
the
the
point
of
why
you
would
want
to
do.
This
should
always
be.
You
know,
true.
A
Right
and
I
see
lucina's
got
a
comment
on
that
pull
request
for
you
so
and
and
pointed
you
at
the
relevant
slack,
which
I
apparently
okay,
yeah.
C
A
That
link
before
the
meeting
ends
out
the
chat
that
will
that
will
help
you
along
okay,
sure
thank
you,
anybody
else
or,
alternatively,
would
you
like
your
day
to
end
early?
Would
you
like
your
morning
to
start
early.
A
Okay,
well,
if
that's
the
way
we're
going
this
morning,
then
I
think
we'll
I'll
give
you
your
time
back
and
you
can
go
and
start
writing
pull
requests
for
me.