Following last week IRC, please find below a suggestion to improve the 
description and the messaging to the wider community about NFV.

I think this group is a great initiative and very important to explain NFV to 
the wider developers community of OpenStack.
While NFV is becoming a more known term for the community (a new and good 
thing!) I feel there is still a gap in explaining why it needs special care. Or 
maybe more precise, do we want to claim it needs special care?
I would claim we shouldn’t think about it as “special” but as a great use case 
for OS with some fine tune needs that are relevant (in most) to other cases too.

So in our wiki we have few great starts.

  *   We have the HL description of ETSI NFV use case
  *   We have the workloads types definition
  *   We have the great section by Calum about two specific apps

What we might consider as missing?
Answering questions like

  *   Why (it) is special ?
  *   Why we need it now?
  *   Who will use it and why it can’t be achieve otherwise?

My feeling is that in order to explain the reasoning we need to emphasise the 
workloads types piece.
We want to avoid using special and specific NFV terms, because they are 
frightening and not relevant for the majority of the community.

So I would suggest to enrich the workload type section. Maybe add more options 
to explain availability schemes needs and other common cases like storing large 
files in burst or any other example.
In addition I would add a section for “transition” time needs just because of 
the state of the apps. A good example for it is the “VLAN” trunking BP. It 
feels more like a transition need (apps today are sending traffic with VLANs) 
rather than a long term real need. In comparison to state or performance needs 
that have a better justification for the long term. My app owners friends, 
please don’t “jump” on the VLANs example, I assume we can argue about it…. I 
hope the point I am is clear though

Then for each section (type)  answer the questions above and link the BPs to 
each of those “types”.

What we will achieve?

  *   Not having special NFV terms as part of the discussion with the community
  *   Clear reasoning for the needs
  *   Not position NFV as not “cloudy”

If make sense, we can start and working on it.

OpenStack-dev mailing list

Reply via email to