►
From YouTube: CNF WG Meeting 2021-06-07
Description
CNF WG Meeting 2021-06-07
A
B
B
A
A
A
A
A
A
A
A
A
A
A
A
That
one's
good
enough
well
good
enough.
I
think
that
one
could
would
be
good
as
a
discussion
item
on
the
discussion
board.
So
for
those
that
don't
know
or
haven't
seen
on
github,
maybe
we
have
a
discussion
area
that
we've
been
using
and
I
think
in
that
performance
related
one.
We
could
have
some
stuff
there
as
well.
E
A
C
E
A
E
E
A
A
A
A
staple
in
the
pull
request:
this
is
a
use
case
that
simon
from
matrix
was
had
submitted,
and
I
think
he
worked
on
that
with
you
oliver
I
I
not
saying
oh
there's,
simon,
hey
simon
it'd,
be
nice
to
get
this
one
through.
I
think
the
main
questions
or
comments
about
this
right
now
were
about
making
some
of
the
use
case,
statements
to
be
either
more
general
or
to
explicitly
say
when
memory
is
being
used.
It's
it
was
one,
I
guess
one
path
versus
the
path.
A
F
F
G
F
G
Then
this
means
like
making
the
such
a
network
function
stateful.
When
we
look
at
the
fast
in
memory
storage,
it
means
that
at
the
points
of
either
node
draining
or
shifting
rescheduling
the
the
pods
or
they
would
need
to
act
as
a
stateful
set
or
if
they
are
not
as
a
stateful
set,
they
would
need
to
have
a
mechanism
to
to
to
consume
or
to
empty
this
or
to
migrate.
This
information,
that
is
in
memory
to
another
node
yeah
or
flash
it
to
the
to
the
persistent
storage
and
then
start
a
new.
F
Yeah,
so
they
are
managed
as
a
kubernetes
stateful
set,
and
there
is
like
an
operator
that
sits
on
top
of
it
that
manages
so.
In
addition
to
like
the
standard,
kubernetes
clustering,
we
have
our
own
clustering
technology,
which
we
use
to
do
like
online
synchronization.
So
whenever
you
interact
with
one
particular
node,
that
interaction
is
synchronized
with
all
of
the
nodes
that
are
in
that
particular
cluster.
G
G
So
I
need
to
to
go
thoroughly
because
now
from
that
point,
I'm
just
thinking
how
to
generalize
it
for
the
use
case,
because
I
would
normally
say
from
the
infrastructure
perspective,
you
got
no
control
over
the
nodes.
You
can
use
the
node
that
you
are
allocated
to
as
a
workload
at
the
given
point
in
time
and
you
will
be
moved
out
of
that
node
via
kubernetes
mechanisms,
which
is
which
is.
F
Kubernetes
at
the
end,
and
it's
the
end
of
the
day,
this
is
basically
what
it
is.
It's
a
it's
an
on.
You
know
an
in-memory
database.
That's
you
know.
You've
got
high
high
performance,
low
latency,
so
yeah
it
has
that
same
so
so
I
guess
this
could
be
written
from
the
perspective
of.
If
you
were
to
stand
up,
you
know
an
in-memory
database
in
kubernetes.
What
challenges
would
you
have
to
think
about,
and
these
are
the
same
challenges
that
I've
tried
to
document.
G
It
is,
we
use
the
flash
arrays
that
are
sitting
in
the
same
wreck
or
in
the
rex,
where
we
have
the
nodes
and
they
are
all
connected
with
with
100
gig
iscsi
and
soon
to
be
nvme
over
fiber
to
that
storage.
But
it's
not
exclusively
storage
for
one
cluster.
It's
it's
shared
between
number
of
clusters,
though.
It's
a
state-of-the-art,
highly
performance
storage
system,
so.
E
So
this
is
interesting
just
to
add
a
point.
I
I
said
last
meeting
that
I'm
working
on
a
on
a
document
about
the
use
of
kubernetes
operators
with
with
our
use
cases,
it's
become
quite
long
at
this
point.
It's
five
pages
long.
Sorry,
it'll
take
some
time.
It's
a
big
discussion,
but
one
of
the
things
I'm
really
examining
is
operators
are
usu
are
useful
in
cases
where
you
need
to
manage
state
a
state.
E
That's
not
non-ephemeral
right,
because
one
of
the
problems
or
challenges,
I
would
say
with
with
the
using
clouds
generally,
is
that
you
think
of
your
resources
as
being
ephemeral.
That
is
kubernetes
can
destroy
them
and
create
them,
and
supposedly
your
application
can
continue
working.
You
know
as
long
as
they're
recreated,
but
things
like
databases-
I
mean,
if
you,
if
you
look
at
the
use
cases
of
kubernetes
operators,
90
of
the
kubernetes
operators
are
database
cluster
managers,
and
it
has
to
do
exactly
with
that.
H
Yes,
something
that
would
be
interesting
there
as
well,
is
so
many
people
when
they
work
with
operators,
they
they
they're,
taking
the
assumption
that
they'll
always
have
a
clean
shutdown,
but
we
know
this
is
not
all
we
know.
This
is
not
true
and
in
terms
of
operators,
it
would
also
be
good
to
tie
in
what
how
an
operator
can
help
you,
when
you
have
something
bad
happening
in
your
system,
like
you
have
some
state
that
the
state
disappears.
H
E
E
You
know
in
certain
kind
of
cluster
arrangements,
you
have
one
one
node,
that's
a
writer
node
and
the
other
nodes
are
reader
nodes,
say
mongodb,
so
you
have
some
sort
of
election
management
system,
so
these
things
kubernetes
has
no
idea
about
them
right.
This
is
something
that
you
need
to
add
to
the
system
to
make
it
viable.
For
example,
cubevert
for
virtual
machines.
E
Has
you
know
one
of
the
requirements
for
virtual
machines
which
doesn't
exist
for
containers
is
that
they
can
be
frozen
and
they
can
be
migrated,
for
example,
to
another
cluster,
as
is
right
with
all
their
ram
and
memory
and
everything.
So
these
are
future
features
that
keyboard
has,
because
it
considers
virtual
machines
to
be
stateful
in
ways
that
containers
aren't.
G
Maybe
we
also
beside
databases.
We
also
noticed
for
a
telco
applications
in
in,
for
example,
if
you
have
a
user
claim
functions
upf.
So
we
work
with
with
one
of
the
vendors
and
the
challenge
there
is
you
have
a
this
upf
pods
or
containers
that
are
holding
customer
sessions
not
for
charging
purposes,
but
for
maintaining
the
connection,
and
when
this
pod
goes,
these
sessions
would
be
either
interrupted
or
they
need
to
be
migrated.
G
So
they
have
a
operator
that
sits
on
top
of
these
upf
pods
and
kind
of
proactively
replicates
all
the
sessions
or
make
a
cache
on
all
other
nodes,
so
that
at
any
given
point
in
time,
if
that
node
or
pod
fails
the
other
standing
that
gets
selected
to
master
or
leader
or
whatever
would
know
how
to
continue
forwarding
the
packets.
So
it's
also
controlled
by
the
by
the
operators
that
are
custom
made
for
that
purpose.
F
For
as
we're
talking
about
operators,
my
view
is
that
operators
really
shouldn't
be
getting
too
deep
into
just
the
secondary
cluster
management
and-
and
maybe
that's
the
the
wrong
viewpoint.
But
I
my
feeling
is
that
an
operator
really
is
just
there
to
help
kubernetes
understand
the
particular
management
requirements
for
the
pods.
F
G
F
G
I'm
not
100
sure,
but
I
I
think
it
reacts
on
the
mo
on
the
on
the
notion.
My
master
upf
pod
is
getting
kicked
out.
So
I
need
to
re
start
the
mechanism
to
select
one
of
my
remaining
ports
as
a
masters
and
create
a
new
one,
and
if
you
are
a
new
master,
you
need
to
to
be
able
to
pick
up
where
the
the
old
master
was
standing.
Something
like
that
not
hundred
percent
sure
is
it
on
which
signals
it
reacts.
F
E
F
E
E
If
anybody
has
a
background
in
functional
languages,
can
guess
what
I
mean,
but
but
but
these
kind
of
pure
operators
don't
have
side
effects
and
indeed
do
what
you
describe,
which
are
they
basically
take
some
kubernetes
resources,
usually
crds
and
manipulate
other
custom
resources.
So,
for
example,
the
built-in
deployment
controller
is
exactly
that
kind
of
pure
operator
right.
A
deployment
takes
a
deployment
resource
and
turns
it
into
a
replica
set
resource
that
it
then
owns,
and
it
doesn't
have
any
side
effects
other
than
that.
E
F
Yeah
yeah
and,
in
actual
fact,
the
operators
that
we,
the
we
have
two
operators
in
our
code
base
and
those
do
have
side
effects.
Although
the
side
effects
are
more
managing
where
we
require
pods
to
start
or
stop
and
and
that's
really
the
limit
of
of
what
we
do,
we
we
use
the
operator
framework
to
you,
know,
bring
workloads
up
and
you
know,
set
configuration
properties
and
those
kind
of
things.
F
A
A
F
A
I
don't,
I
don't
think
you
have
to
remove
the
use
of
memory.
I
think
you
could,
as
you're
saying
your
the
use
case
is
tied
into
a
specific
use,
so
you
could,
if
it
clarifies
maybe
before
that
starts
to
say,
we've
chosen
memory
as
our
solution.
Now
we're
going
to
talk
about
that.
There
are
other
solutions
and
then
it
would
be
fine
address
it
if,
if
it
doesn't
make
sense
to
go
too
generic,
because
that
could
get
confusing.
A
Which
we
may
not
have-
let's
see,
I
don't
see
a
sheesh
on
this
call,
but
this
is
a
there's
actually
two
use
cases
and
there's
a
discussion
item
on
at
least
the
synchronization
timing,
which
I
think
was
relevant
for
the
stateful
stuff,
simon
that
you
had
talked
about,
but
there's
a
discussion,
a
discussion,
one
on
this
one
as
well,
where
there's
some
things
here
and
there's
been
some
topics.
I'm
gonna
just
add
that
discussion
here,
but
this
is
actually
adding
two
different
use
cases.
A
D
A
I'm
not
going
to
go
through
all
that
and
they're,
not
there,
I'm
not
here,
but
if,
if
folks
can
take
a
look
at
these
trying
to
get
it
through,
I
think
vook.
You
had
one
here
this
onboarding,
I'm
gonna,
pull
that
one
up
and
it
looks
yeah.
We
have
some
time
use
case
and
we
need
more
reviewers
on
this.
G
G
G
G
Because
so
far,
if
you
talk
about
physical
network
function,
pnf,
it
was
brought
to
the
the
csp
as
it
is
designed
and
with
a
good
documentation
and
integration
interfaces,
so
didn't
have
any
anything
like
except
the
integration
in
the
wider
environment,
but
in
terms
of
vertical
stacking,
it
was
full
thing.
In
the
vnf
world
we
experienced
that
it
ended
up
mostly
on
application
vendor
bringing
either
own
nfvi
or
nfvi
blueprint,
which
was
stating
the
requirements
and
in
the
in
the
cnf
case.
G
First
of
all,
the
cnfs
are
written
in
a
way
that
they
are
suitable
for
this
service
delivery
or
professional
services
departments
of
the
vendors.
So
if
the
customer
like
csp
team
takes
it,
the
documentation
is
very
much
targeting
people
who
are
very
deeply
into
that
topic.
So
on
the
on
the
vendor
side,
and
it's
also
targeting
every
every
vendor.
G
So
far
we
saw
it
has
its
own
sort
of
platform
and
blueprint
they're
more
open
to
integrate
on
the
third
party
platform,
but
all
things
and
all
know
how
is
kind
of
tilted
towards
this
this
blueprint.
So
we
saw
that
that's
one
of
the
one
of
the
elements
that
makes
it
difficult
to
do
the
onboarding.
That
is
really
not
the
custom
integration.
G
The
second
is,
the
requirements
are
not
clear
up
front
with
having
in
mind
third
party
platform,
so
they
are
usually
coming
in
the
portions
and
we
do
a
bit
of
try
trial
and
error
type
of
onboarding,
so
we
get
the
first
set,
then
fulfill
that
and
start
onboarding
and
say
now.
This
is
forgotten.
That
is
forgotten.
So
what
I
am
trying
to
address
with
this
use
case,
I
I
will
not
go
in
the
in
the
more
aspects.
There
are
a
couple
of
more,
but
it
all
revolves
around.
G
Do
you
have
a
like
a
state-of-the-art
package
for
that
of
that
cnf
that
can
be
used
like
any
kind
of
commercial
software
by
the
teams
to
to
onboard
it
on
the
operating
system
or
install
it
somewhere
and
so
on.
So
the
cns
are
not
in
that
state
at
the
moment,
and
this
use
case
is
tackling
the
needs
to
go
with
some,
let's
say
more
streamlined
and
then
more.
G
And
then
we
do
reverse
engineering
because
we
say
on
our
platform:
we
we
do
something,
that's
more
native
to
that
helm
or
whatever.
So
then
we
are
reverse
engineering,
their
application
coming
to
the
basic
artifacts
and
then
building
up
the
new
packages
so
that
we
can
re
reproducibly,
deploy
it
and
repeat
and
repeat
it
in
the
many
environments.
So
it's
kind
of
I
think
there
is
a
space
for
a
best
practice
discussion
and
maybe
a
broader
consensus.
A
Thanks
fook:
does
anyone
have
any
questions
or
comments?
It's
another
use
case
that
we'd
like
to
get
in
place
and
then
and
specifically
what
book
was
saying,
start
breaking
breaking
down
the
parts
and
looking
for
different
practices
that
we
can
eventually
say.
Here's
good
cloud
native
and
kubernetes
practices,
and
we
want
to
split
those
out
for
those
who
aren't
familiar,
that
one
of
the
end
goals
is
to
make
it
where
you
can
somewhat
all
the
cart
go
in,
and
you
pick
the
different
practices
and
be
able
to
piece
those
together.
E
I
I
guess
one
comment
I
would
make
is
well
it's
it's
a
good
discussion
here.
What
the
challenges
are,
but
some
of
these
challenges
might
be
self-inflicted
if,
if,
if
you
choose
helm
so
that
you
know
the
comment
is
frequently
or
delivered
as
helm
charts-
and
you
know
I
don't
know
how
neutral
that
is
necessarily
right-
there.
There
could
be
other
ways
to
deliver
and
deploy
cnfs.
A
Tell
the
the
idea
here
is
giving
one
example:
that's
fine,
there's,
definitely
multiple
ways
and
I
mean
helm
was
when
it
was
coming
in.
There
were
already
multiple
ways,
so
we're
really
talking
about
how
do
we
help
the
people
that
are
using
helm
and
if,
if
there's
a
other
ways,
then
we
can
also
present
like
letters,
a
use
case
that
could
cover
multiple
paths.
E
G
I
mean
it's.
Definitely
I
think
if
you,
if
you
can
suggest
the
the
edit
on
this
to
make
it
generalized,
it
was
like
one
of
the
the
examples
for
what
we
meet
in
the
practice
and
yeah.
Let's
face
it,
the
helm
is
one
of
the
standards
for
distributing
things,
but
here
what
I
try
to
point
out
is
even
if
they
come
with
the
helm
and
if
you
look
at
the
helm,
best
practices,
they
diverge
very
very
widely.
G
D
G
D
So,
let's
just
be
clear
that
what
we're
trying
to
do
is
not
just
different,
because
it's
cnfs
it's
different,
because
it's
multiple
applications
on
the
same
platform
that
want
serious
quantities
of
independence
from
each
other.
Now
what
we
could
do
ultimately
from
this
is
we
could
write
a
best
practice
that
says,
if
you
insist
on
using
helm,
then
you
should
do
these
things.
That
would
be
a
perfectly
reasonable
best
practice
to
have,
and
I
think
it's
quite
you
know
a
plausible
thing
to
write.
D
D
We
could
work
through
that
and
we
could
make
a
best
practice
that
says:
if
you're
going
to
use
helm,
you
use
it
in
these
ways.
That's
one
thing
on
the
operator
side
of
things
then,
as
yet
yes
operator
is
definitely
a
good
way
of
running
an
application.
You
can
write
an
operator
specific
to
an
application,
they're,
also
a
terrible
way
of
orchestrating
an
application,
because
you're
writing
an
operator
that
effectively
is
part
of
the
platform,
because
it
is
a
platform
service
that
effectively
says
the
application
is
a
platform
service,
that's
its
purpose.
D
G
H
I
think
something
that
we're
missing
here
as
well
is
is
who's
the
audience
for,
for
some
of
these
documents
as
well.
So
is
the
audience
someone
who
is
new
to
kubernetes
who's
tasked
with
operating
this
stuff
they're.
Looking
at
a
green
field
deployment
they're
looking
at
they're
looking
at
something
that
already
exists,
that
has
helm
charts
already
available.
H
E
I
I
I
agree
with
everything
said
here.
My
feeling
just
is
that
maybe
this
use
case
can
be
broken
down,
that
the
the
issue
of
having
the
challenges
having
to
do
with
home
deployment
could
be
its
own
use
case.
I
think
it's
I
I
I
like
this
particular
use
case.
I
think
it
just
it
could
be
made
more
generic
than
it
is
right
now,
because
it,
it
just
addresses
a
very
specific
challenge
that
isn't
necessarily
related
to
these
cases
as
a
whole.
It's
just
related.
D
To
it
so
so
a
better
way
of
phrasing
that
is
rather
than
basically
say
this
is
great,
but
it's
not
what
I
want.
I
think
we
would
say
this
is
great,
but
it's
got
a
certain
scope
so
that
we,
you
know,
it's
not
pretending
to
be
the
solution
to
all
problems,
and
it
doesn't
need
rewriting
to
be
the
solution
to
all
problems.
It
just
needs
to
be
the
solution
to
the
problem
it
describes
and
then,
if
you
want
a
more
generic
one,
you
go.
D
You
write
a
more
generic
one,
because
it
seems
unfair
that
you
want
something
that
hasn't
written,
because
what
he's
written
makes
sense.
So
you
won't
let
him
commit
it,
because
it's
not
what
you
you
would
have
written
yourself.
I
think
write
your
own.
You
know
forward.
Progress
is
valuable
here
right.
If
this
is
taking
certain
assumptions
into
account
and
then
moving
forward
from
there,
then
it
should
document
its
assumptions
and
that's
all
it
needs
to
do.
D
G
Maybe
to
to
highlight
actually
this,
I
think
the
confusion
comes
probably
from
pointing
out
some
specific,
very
specific
things
in
the
limitations.
But
if
you
look
at
the
expected
behavior,
if
I
remember
correctly,
I
put
it
in
a
very
generic
way.
Talking
about
the
actor.
So
here
is
like
a
cnf
devops
team
expects
to
deploy
and
configure
the
cnf
application
on
their
own,
preferably
via
automation,
pipelines
and
interaction
with
the
platform
team.
So
this
is
one
expectation.
G
Then
they
require
well-documented
procedures,
tests
and
so
on,
and
so
on.
So
that's
kind
of
very
generic
how
it
would
be,
but
some
I
would
say
if
you
would
say
some
challenges
and
limitations
with
cube
native
approach.
This
is
depicting
more
or
less
status
quo
and
and
the
practice
which
we
are
facing,
and
this
is
why
it's
singled
out
as
its
pattern
that
repeats,
but
we
could
enrich
this
or
modify
this
or
yeah
for
the
sake.
Anything
in
that
one.
G
A
Point
out
helm,
charts
on
the
limitations
for
the
third
paragraph.
The
rest
is
pretty
generic,
so
we're
and-
and
you
specifically
say,
they're
frequently-
it's
not
saying
that
anyone
else
needs
to
do
that.
It's
that
that's.
That
is
the
case
for
applications
deployed
to
kubernetes
or
frequently-
and
maybe
you
could
say
generally
are
delivered.
So
I
think
that's
okay,
back
in
the
expected
behavior
on
the
second
paragraph
last
sentence:
you're,
you
have
this
part
where
you're
saying
typical
for
cloud
native
applications
and
then
helm,
charts,
containers
and
manifest.
A
Those
are
just
examples,
so
I
think
we're
open
to
expanding
on
this
and
we
could
have
more
specific
ones.
But
this
is
already,
I
think,
pretty
general
and
you
could
talk.
You
could
definitely
talk
about
applications
that
are
only
manifest
files
and
we've
seen
those
doing
some
testing
where
there
you
have
manifest
for
deploying
the
containers.
But
you
do
not
have
helm
charts
covering
all
the
different
pieces
and
there
could
be
other
ways
of
doing
that.
G
G
Yeah,
I
could
talk
in
detail
about
some
some
things
like
you
know.
Many
operators
that
that
tal
mentioned
are
also
coming
packaged
or
to
be
installed
via
hem
charts,
and
we
see
that
many
of
them
install
use
a
hem
charge
to
install
crds
and
helm
is
not
good
at
all
in
handling
crds,
so
they
cannot
upgrade
crds
properly.
G
So
then
we
come
to
the
point
to
to
ask
the
vendors
okay
now
yeah,
we
got
it
installed.
How
do
we
want
to
manage
it
at
the
next
step?
And
then
this
is
where
we
get
discussion
going,
so
I
could
even
provide
the
more
more
technical
insights
behind
these
abstract
things.
I
could
expand
the
list
because
indeed
we
are
having,
in
many
cases,
hem
charts
that
install
the
operators
that
install
then
rest
of
the
things.
E
F
So
is
that
a
limitation
with
the
kubernetes
of
native
approach,
or
is
that
a
limitation
with
the
helm
tool
itself?
I
mean
it's
a
perspective.
Helm
is
the
best
access
or
de
facto
standard
in
any
way
of
delivering
cns.
So
it's
just
a
limitation
of
helm
not
being
able
to
manage
the
life
cycle
of
a
crd
differently,
which,
which
is
to
be
fair,
because
it's
a
cluster-wide
resource
that
really
shouldn't
change
very
often
yeah.
D
Which
is
separate
yeah
if,
if
the
problem
we've
got
a
handful
of
problems
here
again,
you
know
in
theory,
you
can
write
the
crd
for
a
an
operator
that
operates
a
an
application.
Now
I've
got
a
problem.
Okay,
so
I've
got
two
versions
that
application
I
want
to
run
simultaneously
and
they
require
different
versions
of
the
operator
and
that
all
goes
a
bit
kind
of
tips
up.
So
it's
where
orchestra
has
a
slightly
different
thing.
It's
basically
trying
to
say
here's
something.
D
You
know
that
would
work
for
any
application,
I'm
more
sympathetic
to
that.
A
little
bit
like
helm
is
also
application.
Agnostic,
it
doesn't
care,
but
again
you
would.
You
would
probably
want
to
write
a
best
practice
on
that
kind
of
crd.
Saying
here
are
best
practice:
versioning
behaviors
for
crds
for
compatibility,
and
you
know
semantic
versioning
and
so
on.
E
Well,
yeah,
I
mentioned
orchestra
just
that
it
solves
the
chicken
and
egg
problem,
so
it
can
separate
the
creation
to
a
different
chart
of
the
crd,
but
there
are
other
challenges
too.
You
need
an
admin
access
or
some
sort
of
elevated
access
to
create
crds,
yeah
workloads
always
have
them.
Obviously,.
G
D
Yeah
and
that's
my
point:
right
orchestra
could
be
a
part
of
a
mandated
part
of
the
platform
because
it's
not
trying
to
be
specific
to
a
individual,
cnf
or
one
vendor's
set
of
cnfs.
It
would
be
a
good
example
of
something
you
could
make
a
mandated
part
of
the
platform,
but
I
think
what
you
can't
do
and
I
think
we
could
write
a
best
practice
to
this
end
right
now
and
sort
of
start
getting
to
the
point
of
yeah.
Well,
the
world
doesn't
work
the
way
it
needs
to
work.
A
At
the
top
of
the
hour,
I
want
to
ask
so
your
intent
on
this:
were
you
trying
to
be
more
general,
or
would
you
like
to
have
the
because
this
is
real?
This
is
your
use
case
you're
putting
forward.
So
where
do
you
want
to
go
with
this?
It
could
be
something
where
you're
saying
onboarding
of
helm-based
or
helm
package
cns
and
talking
about
the
challenges,
if
that's
what
you're
wanting.
But
where
are
you
wanting
to
go
and.
A
G
My
idea
was
to
illustrate
or
to
specify
the
sect
of
practical
challenges
and
expectations
in
general
related
to
to
say
what
we
call
onboarding,
but
it's
more
or
less
installation,
let's
simplify
it,
installation
of
and
cnf
into
the
kubernetes-based
platform,
so
I
would
prefer
to
keep
it
generally.
It
seems
that
it,
it
triggers
some
discussions
on
best
practices
which
we
could
all
refer
to
this.
G
To
this
point,
I
would
if
there
is
an
interest-
and
this
is
a
feedback
if
there
is
interest
to
to
show
deeper,
what
are
the
specific
issues
with
helm?
We
could
go
in
that
way.
Additionally
and
say
this
is
kind
of
umbrella,
because
it's
not
only
too
specific
to
helm,
it's
specific
to
to
what
audience
what
installation
audience
are
vendors
preparing
those
functions.
Is
it
their
professional
services
team
who
gets
specially
trained
for
that
or
it's
experienced
professional
or
csp?
G
What
is
the
best
practice?
What
we
believe
is
it's
open
to
discussion.
It
is
also
how
they
prepare
documentation,
the
prerequisites
and
so
on.
So
it's
a
set
of
things
out
of
which
we
can
either
derive
a
number
of
practices
and
if
we
feel
helm
or
whatever
is
maybe
more
burning
one,
we
can
focus
more
on
that.
G
So
I
would
prefer
to
to
keep
it
in
this
umbrella
mode
and
maybe
make
it
more
general
or
maybe
make
it
broader
to
to
cover,
let's
say
other
aspects,
and
then,
if
there
is
appetite,
I
could
go
and
then
write
a
separate
one
like
use
case,
best
practices
or
challenges
with
the
help
based
deployments,
but
that
one
would
go
then
in
in
the
details
of
where
the
things
are.
Failing
what
specifically
in
helm,
we
see
as
a
challenge
and
so
on.
A
A
All
right
I'd
be
up
for
working
with
you,
some
and
trying
to
see
if
we
can
expand
and
call
some
of
the
things
out,
but
it
sounds
like
we're.
Not
we're
not
saying
here
is
we've
solved
problems,
but
laying
out
a
bunch
of
the
problems
that
are
there.
Maybe
is
what
you're
pointing
out
here.
So
this
would
be
talking
about
the
problems,
and
then
we
may
have
follow-up
use
cases
and
then
eventually
best
practices.
That
point
back
and
say
this
saw
helps.
Try
to
solve
one
out
of
the
larger
set.