►
From YouTube: CNCF CNF WG Meeting - 2023-08-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
Yeah
nice:
let's
wait
a
couple
of
minutes
to.
A
Yeah
with
the
Audi,
oh
now,
it's
she's
back,
hey
Lucina,.
A
Let's
go
a
couple
of
minutes:
I
don't
know
if
someone
else
is
also
going
to
join
last
week,
Oliver
and
Taylor.
We
were
you.
B
A
Like
a
having
a
working
session
and
tried
to
complete
the
what's
the
name
of
principle,
one
concern
for
container
principle,
so
I
don't
know
if
we
are
going
to
continue
on
that
or
we'll
have
a
regular
meaning.
B
B
C
Yeah
Victor
you're
Laden
today,
yeah.
A
C
Guess,
let's
get
started
if
we
have
a
short
one,
that's
fine
or
we
can
turn
it
in
a
working
session.
Whatever
we
want
to
do
today,.
A
Well,
I,
don't
know
if
should
I
just
go
through
the
scrolled
in
things
that
we
have
in
our
agenda
like
that.
C
A
The
other
one
that
I
haven't
heard
anything
is
about
the
the
nephew
TC
and
developer
Summit.
A
They
were
proposing
two
different
weeks,
but
one
of
the
things
that
I
noticed
is
one
of
these
weeks
or
were
conflicting
with
a
this
is
yeah
the
open
source
Summit,
especially
the
second
one,
so
I
don't
know
like
at
the
end
of
the
day,
they're
going
to
choose
only
what
the
first
option,
the
only
one
who
who
is
not
making
conflict
like
the
September
11.
It's
not
a
little
conflict
with
with
with
this
September
19
week,.
A
C
Let's
take
a
look
at
the
one
concern
per
container
I
guess
unless
you
want
to
well
I,
don't
think
there's
enough
of
us
to
look
at
what's
the
next
one,
let's
try
to
knock
this
one
out
and
then
maybe
we
can
look
at
what
the
next
one
would
be
and
I
know
you
and
I
had
talked
about
stuff
related
to
nafaya,
so
probably
something
to
dig
into
next.
A
C
D
A
C
I
I
think
we
should
defer
that
that,
rather
than
let's
take
a
look
at
that
one
process
and
then
if
there's
nothing
to
nothing
new,
then
we
can
either
work
on
it.
I
think
we
should
work
on
it.
That's
what
I
was
going
to
say
and
then
later
we
can
look
at
the
nephio
stuff.
Okay,.
A
A
So
well,
well,
we
have
been
trying
to
do
is
just
make.
Let
me
check
yeah
this.
Is
it
the
rice
broth
right?
So
we
have
tried
to
make
this
particular
graph
completed:
Oliver,
Taylor
and
I.
We
haven't
tried
to
yeah
being
over
here
with
the
definition
and
all
these
things
I
think
there
are
several
sections
who
has
ready
to
go.
Others
have
definitely
we
need
more
feedback,
so
I
will
give
a
plenty
of
time
to
take
a
look.
A
A
C
I'm
good
with
that
summary
ildica,
do
you
have
any
feedback
for
this?
So
This
best
practice
about
we're,
not
quite
sure
on
the
name,
it's
kind
of
shifted
several
times
it
was
one
process
for
container
and
one
process
per
category
I
think
existing
tests
right
now,
that's
in
the
test,
Suite
is
checking
for
it's
multiple
process.
Types
in
a
single
container
is
what
it's
trying
to
look
for
as
a
not
a
good
practice
in
general.
C
So
the
idea
of
this
is
related
microservices
and
trying
to
separate
concerns
and
then
helping
to
break
down
Services
onto
their
component
parts
to
for
size,
so
you're
not
going
to
keep
expanding
you're
not
trying
to
take
too
many
things.
You
know
all
the
different
reasons
benefits
about
microservices
is
one
of
the
main
drivers.
A
B
A
Right
yeah,
this
is
biscuits.
They
came
from
from
Docker
as
the
best
practice
yeah.
This
is
something
that
we
are
referring.
The
rack
section
is
a
motivation.
When
we
were
reviewing
motivational
goals,
we
were
a
little
bit
confused.
That's
why
we
tried,
to
put
it
like
a
a
small
reminder,
what
we
consider
like
a
motivation
and
in
this
particular
case
we
split
it
into
main
audience.
A
A
So
that's
where
we
have
a
few
points
here
and
probably
we're
going
to
add
folders
here
as
well.
For
us
motivation
is
basically
this
experience
on
from
the
past
so
so
or
things
that
they
want
to
avoid.
A
For
for
that
particular
case,
in
this
case,
for
example,
The
Operators
have
been
pasted
with
the
security
issues
or
like
issues
during
the
troubleshooting
process
and
and
they're
they're,
trying
to
avoid
those
particular
problems
so
I'm
using
this
particular
best
practice.
How.
A
A
B
C
C
I
mean
the
the
top
part
is.
Obviously
this
is
just
the
definition
description,
but
we
don't.
We
shouldn't
have
that
in
later,
but
the
rest
of
it.
C
I
think
we
were
talking
about
moving
the
benefits
down,
but
that's
to
the
goals
section
go
ahead
and
accept
the
top
part
and
then
we'll
adjust
this
foreign.
A
A
A
A
A
If
you
split
the
services
seem
to
Containers,
you
have
to
start
thinking
about
how
to
communicate
between
these
two
things
like.
Let's
say
that
you
have
one
process
like
memcache.
If
we
were
like
using
the
other
side
a
primary
example,
so
when,
when
you
have
Main
Catch
on
the
web,
server
in
the
same
container.
B
A
C
A
A
I
think
we
lost
Terror
again,
no.
C
I'm
here
I'm
just
trying
to
think
of
everything
for
the
development
for
what
I
was
saying.
A
C
E
C
So
if
I'm
thinking
like
bugs
and
everything
so
just
the
service
offering,
if
you
have
a
component,
that's
minimized
to
the
single
concern,
then
you
do
have
you
got
to
make
sure
that
the
surface
wherever
the
communication
is
going
to
happen,
is
solid
but
internal
to
it.
You
simplified
issues
so
bugs.
If
there's
anything
is
it
it,
and
this
goes
back
to
the
first
one.
C
If
you
know,
if
there's
multiple
components
and
different
groups
and
stuff
and
someone
introduces
a
bug
in
one
area
but
you're
tightly
coupled,
then
you
end
up
with
potentially
having
bugs
in
other
areas
that
as
a
result,
so
if
you're
Loosely
coupled
on
those
components,
then
someone
can
do
their
development
if
they
introduce
a
bug.
And
ideally
it's
not
going
to
introduce
a
bug
for
the
others.
C
If
you're,
if
you
make
sure
that
the
handshake
between
them
is
strong
and
you're
going
to
make
sure
that
works,
and
even
if
you
break
something
else,
you
didn't
break
everything
and
then
that's
similar
for
stuff
like
if
someone
introduces
a
new
feature
and
they're,
not
as
worried
about
breaking
everything,
because
they
can
keep
it
internal.
A
E
A
I
was
thinking
is
like
is:
is
that
one,
not
the
area
of
operator
right
so
yeah?
If
you
talk
about
like
when
a
developer
has
to
fix
a
book
yeah,
probably
it's
going
to
be
easier
like
because
they
have
we're
talking
about
modifying
source
code.
C
Hopefully
the
problem
is
more
visible
to
being
a
single
component,
and
then
they
can
report
that
or
whatever
and
then
you're
also
going
to
just
have
bugs
that
developers
find
themselves.
Maybe
you
know
during
more
extensive
testing
or
before
it
ever
gets
out
of
staging
and
moves
on
to
the
customer
or
something
so
I.
We're
gonna
have
overlap
on
all
those
I.
Don't
I,
don't
think
we
should
try
to
keep
it
all
separate.
If,
if
they're
doing
the
same
thing,
I
think
that's
okay,.
A
Okay,
because
the
other
thing
is,
it
could
be
like
a
in
terms
like
you
need
that
you
know
Fusion
of
testing
I
guess
would
be
more
effective
if
you
only
have
to
do
the
functional
test
or
like
the
unit
test,
when
your
container
only
focus
in
one
single
thing.
Instead
of.
E
It's
interesting
so
motivation.
C
So
we're
we're
kind
of
what
is
the
benefit
versus
the
motivation,
so
a
motivation,
I'm
just
gonna,
say,
increase
test
coverage.
D
C
C
C
The
goal
is
something
you
wish
so
it
may
I
may
forget
it
right.
The
goal
is
to
give
them
confidence,
motivation
exactly.
B
C
So
the
goal
is
confidence
and
test
coverage.
Motivation
is
yeah,
so
they
motivation
test
coverage
over
a
complex
CNF
is
difficult
to
say
because
of
tightly.
B
C
There
we
go
so
now,
so
this
is
the
motivation,
that's
their
motivation.
So
then
our
goal-
I'm
gonna,
just
put
it
here.
A
C
So
the
motivation
here
so
this
is.
C
Can
I
I'm
just
going
to
write
it
out,
then?
Maybe
we
just
can
block
each
other.
Each
other's
development
process.
A
C
C
Yeah
hold
on
one
second
foreign.
C
We
go
I'm,
gonna,
I'm
gonna.
Do
this
in
here
and
then
show
you
what
I
said.
B
B
C
C
This
is
telling
us
what
each
one
of
these
sections
are,
but
it
doesn't
actually
give
the
definition,
which
is
why
I
added
in
that
pull
request.
But
you
can
see
the
example
here.
Motivation.
C
All
right
so
I
created
a
pull
request
to
add
to
this.
This
is
more
of
how
do
you
propose
a
best
practice,
this
document,
the
first
one
and
going
through
all
the
areas
so
on
motivation.
C
And
they're
putting
them
in
the
motivation.
It's
saying
why
you
would
do
that
without
Center
mechanism
for
describing
important,
quantitative
best
practices,
The
Wider,
Telecom
Community
will
struggle
to
understand
the
importance.
So
this
is
the
motivation
behind.
So
then
the
goal
is
provide
a
standard
way
for
the
community
to
propose
and
discuss
spot
native
definitions.
That's
the
what
there's
this
in
this
document
like
why
it's
here.
So
why
are
we
doing
this
at
all
so
they're
giving
here's
the
problem?
C
C
And
that
could
be
out
of
scope,
and
this
is
trying
to
be
more
formal
with,
as
is
the
main
reason
to
split
these
up
into
totally
different
sections,
the
motivation
and
then
goals
versus
having
an
intermixed.
Where
you
would
say,
let
me
give
you
one
and
then
let
me
show
what
we're
trying
to
do.
C
C
It's
just
expecting
that
you
actually
read
it.
So
that's
why
we're
following
that
whenever
we're
going
here,
so
we
have
the
motivation.
I
mean
I,
put
motivation,
angle
but
motivation
here.
So
this
is
the
problem
and
then
the
goal
is
how
we're
trying
to
solve
it.
So
we
really
could
call
this
challenge
and
then
you
know
solution
and
then
out
of
scope
or
objective
or
whatever
yeah
I,
don't
want
to
change
all
that
right.
Now,
no.
C
May,
putting
this
into
the
actual
PR
I
mean
apparently
no
one
looks
at
him
anymore,
but
the
the
this
definition,
but
the
pull
requests
that
I
was
putting
I
was
trying
to
do
that.
We'll
see
how
it
is
like
the
template's,
probably
a
better
place,
Whenever
However
They're
copying
it
over.
C
We
just
want
to
delete
it
out,
but
it
would
say
something
like
motivation
is
the
challenge,
and
it's
that
the
end
user
has
so
motivation
is
a
challenge
is
something
the
end
user
has
from
the
past,
and
it's
something
you
want
to
help
overcome
with
your
going
right.
So
then,
that
goal
is
something
in
the
future.
We're
trying
to
get
to
the
objective.
C
I
I
think
we
need
a
little
work
on
the,
how
we
introduce
it,
and
maybe
maybe
this
would
be
a
good
thing.
Lucina
you've
put
forward
in
the
past
and
we've
done
it,
and
it
sounds
like
it's
time
to
do
it
again
as
introduction
to
the
working
group
and
how
people
can
get
get
involved.
C
So
the
fact
that
we're
struggling
to
talk
about
this
means
that
other
people
are
going
to
have
a
harder
time,
so
I
think
we
could
go
in
and
update
this
at
a
minimum.
Have
it
like
a
high
level
and
saying
what
what
are
these
best
practices
and
go?
Okay,
the
Telecom
Community
has
challenges
and
we're
listing
those
as
the
motivation
for
what
the
best
practices
are
trying
to
solve
the
object.
C
C
Probably
have
it
like
as
the
updated
intro
there's
the
contributor
document
or
something
that
we
could
update
and
and
maybe
link
from
the
readme
how
to
get
involved
something
and
then
maybe
have
a
work
on
something
for
like
an
introduction.
Like
a
I.
Don't
know
15
minute
presentation
or
something
for
the
future
conference
or
whatever.
C
D
I
think
it
mostly
does.
My
brain
also
needs
a
little
time
to
process,
but
as
as
we
talked
it
through
here,
it
did
make
sense
or
it
does
make
sense.
E
C
So
Victor
thinking
about
it
from
motivationist
challenges
and
goals,
are
the
objectives
to
help
solve
those
challenges.
I
think
we
could
reword
some
of
these
I've
started.
C
So
this
one
is
the
tightly
coupled
and
this
one
is
actually
the
gulls.
So
we
we
should
move
that
down.
We
want
to
reduce
the
complexity
of
individual
components
and.
A
C
C
Yeah,
this
is
a
motivation
and
then
this
is
a
goal.
Allow
multiple
groups
to
maintain
the
independent
development
life
cycle,
their
own
development
maintain
sorry
they're
on
Independent
development,
life
cycles.
C
So,
oh,
we
have
the
increased
confidence.
I.
Think
you
put
an
increased
confidence
test
coverage,
so
I
kind
of
feel
like
I
learned.
That's
actually
part
of
this
reduce
complexity.
A
A
I
was
saying
is
like
maybe
like
like
like
specifying
the
details
like
implementation
details.
I,
don't
think
that
we
have
to
specify
how
to
to
to
to
split
the
things
or
like
the
logic
that
they
have
to
follow.
B
C
I
want
to
say,
locate
and
close
in
there's
something
difficult
to
it's,
not
just
fine,
but
like
reduce
the
area
difficult
to
find
where
the
bug
is.
A
C
So
you
make
a
oh,
the
bug
is
in
the
CNF,
that's
different
from
going.
Oh,
it's
in
this
one,
one
CNF
that
has
like
15
different
services
that
it's
providing
it
might
be
a
lot
harder
to
find
like
which
part
of
this
is
actually
causing
the
problem.
B
C
Yeah
but
I'm
talking
about
like
identify
identifying
it's
fun,
but
it's
like
reducing
you're
trying
to
reduce
the
area
if
it's
a
complex
CNF,
but
you
have
it
broken
into
microservices,
and
it's
more
likely
that
you're
going
to
see
the
problem
on
one
component
and
it
that
component
may
actually
not
be
the
problem,
but
they
can
at
least
go
and
immediately
investigate.
One
component
then
go
oh.
B
B
A
Because
then,
my
my
brain
only
brings
I
didn't
idioms
like
identify
and
discover
things
like
that.
Yeah.
A
C
Identify
I'm,
gonna
use
this
potential
component.
C
Something
like
that,
okay,
so
these
are
the
motivations
and
then
the
this
area
is
actually
goes,
reduce
the
attack,
surface
area.
C
Simplified
troubleshooting
readouts,
so
we
don't
really
have
that,
so
they
something
about
its
instead
of
making
something
visible,
you're
obscuring
it.
It's
opaque.
So.
C
So
when
they're
tightly
coupled,
then
you
don't
really
know
what's
going
on,
but
if
they're
broken
into
microservices,
then
you're
gonna
have
the
communication
as
well
defined
between
them.
They
could
potentially
have
log
output
where
it's
you
could
have
like
CNF
name
and
component
name.
So
then,
if
some
there's
a
problem,
then
that'll
help
find
troubleshoot.
C
Yeah
it
doesn't
mean
that
they're
not
going
to
have
it,
they
could
have
an
internal,
they
could
have
it
all
tightly
coupled,
but
then
log
stuff
separately,
but
if
you
are
already
intentionally
separating
them
into
microservices
and
that's
visible,
then
I
think
you're,
more
likely
gonna
have
your
logging
and
stuff
separated
because
you're
already
having
to
run
them
independently.
So
on
the
development
side,
you're
going
to
do
that,
mm-hmm.
C
This
was
before
I
think
this
General
goal
is
true.
We're
gonna
make
this
a
different
color,
so
we
know
to
remove
it
later.
C
If
they're
broken
into
microservices,
then
you're
going
to
be
taking
advantage
of
the
kubernetes
orchestration,
more
I
think
you
brought
this
up,
maybe
the
architectural
practices.
So
if
your
microservice
architecture
practices,
if
you're
breaking
it
down,
then
you
can
start
taking
advantage
of
more
of
those,
so
I
think
that's
kind
of
a
developer
view
as
well,
but
it
it
does.
If
there's
Ops
Team
know
that
you're
following
that,
then
they
can
probably
train
and
build
their
environment.
C
We're
gonna
do
it
like
that
reduce
the
tax
service,
simplified,
troubleshooting,
readout
I.
Think
that's
that
one.
So
we
can
remove
that
upgrading
process
types
independently.
So
we
didn't
talk
about
that
as
a
motivation,
but
that's
a
motivation
really
for
I
mean
developers
may
or
may
not.
I
mean
I
think
they
do.
When
we
talk
about
like
this
one
tightly
coupled
right
here,
didn't
I
care
about
it,
but
we
can
also
put
it
up
here
so
so
the
motivation,
a
challenge
for
the
CS
piece
they
on
upgrades
so.
C
A
B
A
C
So
you
could
actually
roll
back
independent
Paces
or
call
it
off.
You
know
I
mean,
of
course.
This
all
requires
people
to
do
that
work,
but
all
right
I'm
going
to
move
this
oops
I
just
went
too
far,
I'm
going
to
remove
the
goals
down
from
the
developer
and
then
I
think
we
sought
because
they're
four
minutes
over
so
under
the
developers
talking
about
different
organizations
or
groups
that
are
all
doing
maintaining
and
we
want
to
make
it
independent
so
that
they
can
work
by
themselves.
So
I'm
going
to
move
that
goal
down.
C
We've
got
a
total
effect,
saw
this
bottom
area,
it's
hard
all
right
and
then
we're
saying
test
coverage
is
difficult.
Whenever
they're
totally
coupled.
B
C
We'll
stop
here.
This
is
a
good
chunk.
I
think
we
can,
if
we
can
move.
A
lot
of.
This
was
out
of
the
document
that
Oliver
copied
over
the
there's,
a
blog
post.
That's
linked
yeah.
A
C
Think
if
we
can
clear
this
section
out
and
move
it
into
either
goals
or
turn
them
into
challenges,
then
that'll
cover
most
of
it.
The
out
of
scope
will
be
pretty
straightforward
and
the
proposal
is,
you
know,
based
on
content.
That
is
right
out
of
the
document.
I
think
the
the
challenges
and
and
objectives
were
a
more
difficult
thing
to
cover
on
this.