►
From YouTube: CNCF CNF WG Meeting - 2021-11-08
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).
C
A
Well,
I
have
something
around
the
best
practice
categories
that
I
put
in
there.
A
B
A
And
I
don't
see
any
new
discussions
or
I
mean
look
at
pull
requests.
There's
no
open
pull
request.
I'm
going
to
share
my
screen.
Maybe
that'll
be
easier.
A
So
no
pull
request
open
issue
wise
one
of
them's
about
adding
a
category
that
we
haven't
had
in
the
cnf
organ
group,
but
it's
existed
for
six
months
or
more
in
the
test
suite
resilience,
but
I
won't
delve
into
that
because
we're
about
to
talk
about
categories
define
cube
native,
I
don't
know
I
feel
like
this
one.
A
A
A
Oh,
this
one's,
probably
still
a
good
one,
the
ian
put
forward
and
we
have
discussions
about
it.
We
have
a
bunch
of
docs
from
the
last
three
months
about
least
privilege,
principal
police
privilege.
A
A
A
All
right,
if
everyone
has
comments,
please
so
best
practices,
I'm
gonna
have
to
go
over
this
when
there's
more
people
as
well,
but
for
those
that
are
on
it.
So
we
have.
A
Here's
the
categories
other
than
resilience
that
we
have
configuration
life
cycle
stallable
all
these
things
observability
it
doesn't
have
resilience,
that's
the
one:
that's
not
there,
and
and
there's
been
questions
about
updating
some
of
these
for
a
while
and
comments
on
the
cnf
test,
suite
so
related
for
the
documentation
and
publicizing
on
practices
that
we
do
in
the
working
group
test.
Suite
testing
those
things
been
talking
about.
A
Updating
these
the
first
two
are
kind
of
areas
of
concern:
hardware
support
an
area
of
concern
and
then
we
get
into
stuff
like
we
expect
observability
security
area
of
concern.
We
expect
compatibility
and
how
to
make
it
where
there's
area
these
categories
are
sections
that
we're
going
to
have
practices
in
them
and
that
we
can
test
those
practices
they
make
sense,
they're
valuable.
A
A
I'm
going
to
give
kind
of
a
a
draft
of
what
we
were
thinking
about
right
now.
Some
ideas
potentially
update
draft-
or
maybe
I
call
it
work
in
progress.
A
So
right
now,
there's
10
in
the
test
suite
nine
on
the
working
group,
but
I
think
we'd
add
resilience
because
we've
had
a
lot
of
what
would
be
good
practices.
You
there's
a
lot
of
things
that
you
want
to
cover
on
resilience
and
availability
and
stuff
so
that
just
hadn't,
there's
ticket
open
just
10
minutes.
A
We're
looking
at
here
is
some
merging
and
updates
around
naming
the
configuration
lifecycle
is
so
large
that
you
end
up
with
all
so
many
different
things
all
covered
in
one.
It
becomes
a
massive
category.
So
what
we've
done
here?
The
suggestion
is
to
split
it
up
the
life
cycle,
kind
of
gets
merged
and
the
parts
in
life
cycle
get
merged
into
other
areas
that
cover
what
it's
doing
and
you
the
configuration
would
be.
A
Potentially
we
could
rename
it,
but
what
we're
really
talking
about
is
declarative
configuration
both
for
what
you
think
of
like
the
config
files,
the
what
you
need
to
do
to
get
something
ready
deployment
and
you
know
all
the
way
through
upgrades,
but
also
stuff
around
like
declarative
apis.
All
everything
declared
us.
So
this
is
what
that's
about
so
maybe
it
should
be
declarative,
configuration
or
something,
but
that's
that
category
this
one.
A
A
Applications
how
they
work
together,
how
they
work
with
platform,
how
you
can
deploy
new
versions
downgrade
all
of
those
sort
of
things,
there's
a
whole
lot
of
security
one.
So
this
one's
becoming
a
large
category
and
potentially
security
could
be
part
of
everything.
But,
right
now
it
seems
like
people
are
gonna.
Look
for
it,
so
we're
not
suggesting
to
merge
that
state.
A
Also
would
be
something
where
there's
going
to
be
faithfulness
in
a
lot
of
areas,
but
right
now
it
seems
like
pointing
those
things
out
is
important,
so
keeping
that
separate
micro
service
observability
same
sort
of
things
that
resilience
category
merging
scalability
would
merge
in
with
these.
A
So
there's
a
scaling,
or
I
think
it's
called
it-
is
called
scaling
here
that
merges
in
so
talking
about
how
available
it
is.
Reliability
is
an
indicator,
so
we
don't
have
reliability
right
now
as
a
category,
but
that's
what
we're
talking
about.
With
regard
to
services,
we
want
the
services
to
be
available
and
reliable,
adding
resilience
and
different
practices
on
making
things
available
and
stuff.
That's
what
this
is
about
so
yeah.
A
B
I
have
a
question
taylor.
I
think
the
to
me,
the
the
categories,
makes
sense,
I'm
just
curious
as
you're
referring
to
the
test
suite,
since
there
are
tests
already
in
the
test.
Suite
do
you
do
you
see
any
way
we
could
actually
bring
those
best
practices
that
are
in
the
test
suite
into
these
categories
in
some
way
like
you're,
just
referencing
them
or
pointing
to
them?
I
don't
I
don't
know
I'm
just
I'm
not
saying
it's
a
good
idea,
I'm
just
curious,
since
there
are
categories
and
there
are
tests
today.
A
B
That
what
you're
I'm
just
trying
to
make
sure
I'm
understanding
yeah.
I
think
that
I
think
that's
what
I
think.
That's
what
I'm
saying
I
was
just.
I
was
just
reacting
to
the
fact.
I
mean
you're,
mentioning
these
categories
and
the
fact
that
you
have
the
categories
in
the
test
suite
as
well
yeah
and
I'm
just
thinking
to
myself.
The
test
suite
is
obviously
not
empty.
You
know
there
are
tests
that
are
fulfilling
some
purpose
around
some
of
these
different
categories.
So
my
question
was
really
you
know
what
would
prevent
us?
B
A
A
But
that's
you
know
it's
it's
it's
an
area
I'm
trying
to
work
on
some
my
place
pretty
full,
but
I'm
I'm
trying
to
do
that
for
sure
and
anyone
else
who
would
like
to
to
do.
That
would
be
happy
to
to
work
with
work
with
you
on
it.
A
And
that
can
make
it
you
know
potentially
easier
to
to
add
new
categories
since
we're
working
from
something
that
already
has
content,
especially
newer
tests,
we're
trying
to
add
the
why
why
it's
valuable,
what
it's
testing
and
wherever
possible
remediation
type
of
results,
which
may
point
to
say
upstream
documentation,
here's
where
kubernetes
talks
about
this
thing
or
whatever,
and
that
can
help
with
writing
up
the
best
practice
content
in
the
working
group
and,
of
course,
expand
on
or
add
new
user
stories
or
use
cases.
A
A
It
actually
has
a
lot
more,
but
here's
a
chunk
of
them
from
the
snapshot
back
when
it
was
created.
Some
microservices
configuration
lifecycle
installability.
So
what
we'd
want
to
do
is
go.
Look
at
the
you
know,
newest
what
what
the
newest
set
are
and
can
go
in,
like
here's
all
those
resilience,
things
that
we're
talking
about
so
yeah
for
sure
we
could
go
in
and
and
do
that
for
all
of
these
categories.
B
Okay,
yeah
and
it
may
not
be
the
right
that
we
do
them
right
now.
I
mean
it
may
make
sense.
I
was
just
thinking
you
know,
as
we
have
these
categories
and
start
populating
some
of
the
tests
or
best
practices.
We
already
have
you
know
unless
they,
unless
we
don't
agree
with
them
to
your
point,
you
can
change
them,
you
can
add
them
delete
them.
It
kind
of
allows
us
to
move
from
an
empty,
empty
categories
to
to
starting
to
populate
some
of
those
yeah
all
right.
Thanks.
A
We
have
this
compatibility.
Installability
upgrade
ability
which
takes
some
of
the
configuration
life
cycle
takes
this
since
installation
upgrade
and
merges
that
this
reliability,
resilience
and
availability
is
merging.
Some
of
the
things
from
lifecycle
scaling
into
that
one
hardware:
support
which
could
get
a
little
bit
of
the
configuration
or
compatibility
as
well.
B
A
C
A
And
be
part
of
some
of
it's
trying
to
communicate
we're
trying
to
communicate.
What
are
you
getting
out
of
this
or
what
is
a
very
important
area
with
the
way
these
are
set?
Security
would
be
one
that
can
go
either
way,
but
it's
something
everyone
is,
you
know
recommending
so
and
highlight
it
right
now.
A
A
But
you
want
to
make
sure
I
think,
from
the
standpoint
of
especially
the
telecom
industry,
it's
tying
into
service
reliability
and
are
your
services
always
there
and
available,
and
and
then
you
get
back
to
resource
efficiency.
So
I
guess
it's
decreasing
the
resource
efficiency,
that's
kind
of
the
thinking
there.