Ops-telecom-nfv

OpenStack Operators Telecom/NFV Functional Team

Status: Active

Organizers:
 * Curtis Collicutt, , IRC: serverascode
 * Your name here?

Mission Statement
The OpenStack Operators Telecom and NFV Team will work with the OpenStack community and ecosystem to benefit OpenStack Operators specifically running telecommunication services and Network Function Virtualization (NFV) systems utilizing OpenStack.

To achieve this, with each release the group identifies requirements most commonly raised by the telecommunications and NFV operator community and ensures action is being taken to address the requirements in an appropriate way, including, but not limited to, liaising with developers, raising and highlighting bug reports, and generating reports or documentation. As well, in situations when a larger requirement is identified, occasionally the team will develop a mid to long term plan to shepherd said requirement through the OpenStack community.

For each release the Working Group will produce a record of issues identified, what is being done to resolve them and an expected timeline.

How to Join

 * 1) Sign up to the openstack-operators mailing list and look for posts with "[telecom-nfv]" in the subject
 * 2) Attend our bi-weekly meetings
 * 3) Slightly less used, but available, is the #openstack-nfv IRC channel on Freenode. Also, OPNFV has an #opnfv-openstack channel.

Structure
Currently we have bi-weekly meetings. Please see the meeting page for more information on time and place. Like most OpenStack meetings, they take place on IRC. Logs from previous meetings can be found online. To help plan the next meeting or your attendance go to the Agenda Etherpad

OPNFV
As our team crosses several areas, from OpenStack to telecommunications, we also work with the Open Platform for Network Function Virtualization (OPNFV) organization, which is part of the Linux Foundation.

OPNFV is a new open source project focused on accelerating NFV's evolution through an integrated, open platform.

The OPNFV has a wiki page dedicated to related OpenStack projects.

Mid to Long Term Project
Currently we are working to determine a medium sized project to work on over a mid to long term time frame. What "medium sized" and "mid to long term" actually mean are still being determined.

There is an etherpad page with some ideas listed. If you have requirements you think would be good for this functional team to work on, please feel free to add them to that page. Projects could vary from performance testing to working with OpenStack projects to add requirements.

FAQ
1. What is this group for?

This is a question we often get. We are working on our mission statement which you can read at the top of this page. Hopefully that is a good start. To go further than that mission statement, what we want to do is make operating an OpenStack Telecom/NFV related cloud easier. That can mean all kinds of things, from developing operational tools, to shepherding requirements through the OpenStack ecosystem, to performance testing and bench marking, to creating design documents.

We know there are people out there actually running NFV clouds on a day to day basis, and we want to try to help them do that. Currently telecommunications companies have a few requirements that other organizations may not have. The same can be said of running a public cloud with OpenStack as opposed to a private one. There are slight differences, operational models, and changes in focus, which draw out different requirements that have to be met in some fashion.

Our goal is to determine those requirements and help to meet them, typically from the perspective of an OpenStack Operator, be it someone who runs a production cloud, or someone who runs a test system in a lab, or anywhere in between.

2. Do I have to be an "OpenStack Operator" to be part of this functional team?

No. While certainly the goal is to ensure that OpenStack Operators have all the tools, requirements, and functionality they need to do their work, there are many different facets to operating OpenStack clouds, and all opinions are welcome. Further, this team will be required to interact with many parts of the OpenStack ecosystem, not just other OpenStack Operators.

3. Wasn't there a telecom related working group previously?

Yes there was. However, it seems they met their goal of creating telecom/NFV related user stories, and those stories were moved into the product working group. With that completed the working group meetings were suspended. See this email message for more information.

Further, the OpenStack Operators Telecom/NFV Functional Team, is related to OpenStack Operators and helping them to manage OpenStack clouds with telecommunication and/or NFV use cases, and thus has a somewhat narrower scope than the Telco Working Group.

Finally, another difference exists in that this is a functional team as opposed to a working group as defined by the User Committee.

4. Telecom "operators" versus OpenStack "Operators"

In telecommunications, the word "operator" has a different connotation than in OpenStack. Generally speaking, an "operator" in telecommunications context is some kind of communication service provider. Usually a telecommunications company.

In OpenStack, an operator is someone who runs an OpenStack cloud...someone who is responsible for deploying, and/or designing, and/or maintaining an OpenStack cloud. Usually they have day to day responsibility for an OpenStack deployment. Typically their job is to operate the cloud over time, which includes tasks such as performing upgrades, managing scalability, and making other operational decisions.

It is unlikely that either group will change their use of the word any time soon, so we will just have to deal with the occasional confusion.

5. Isn't this just another requirements gathering exercise?

During our bi-weekly meetings we have had comments and critiques of this sort. Also there is some concern that we would be yet another group that would annoy OpenStack developers, which is a fair point.

Our hope is that this will not be the case, for at least two major reasons. The first is that getting features or other code changes into OpenStack projects is not the only way to achieve our goals. There are many other things we can be doing, such as creating performance testing reports, or writing our own operational tools, etc...things that will not require OpenStack projects to write code. Secondly, if we do decide to work towards getting a feature added in an OpenStack project, we will engage the development team early in the process to ensure that we are not proscribing a solution, and instead are communicating a desired feature, as well as the reasons for that feature. The why and not the how.