- OPNFV project team members do their blueprint draft reviews in Gerritt before submitting blueprints to OpenStack
- After reviews are completed in OPNFV, OPNFV project team member(s) submit blueprints/bug in OpenStack
- After blueprints are accepted, OpenStack blueprints will automatically list all relevant OpenStack Gerrit IDs
- OPNFV project team will add the blueprint links in a file in OPNFV that is similar to the current project INFO file
- Bitergia to track the OpenStack Gerrit IDs in the blueprints listed in the "INFO-like" file in step 4 above
- e.g. who's contributing to OpenStack, how their blueprints are progressing in OpenStack, etc.
- Bitergia has full access to our repo's incl. the INFO-like file.
- Can also get historical data (by adding old blueprint IDs)
- No need to do anything differently in OpenStack (e.g. no special tagging for OPNFV)
(Question: how do you deal with bugs without blueprints? Use bug reports?)
OpenStack and OPNFV projects and contacts
This list of the primary OpenStack and OPNFV projects, with links to the wikis and Project Technical Leaders, is designed to facilitate collaboration. Please follow the blueprint process below to request features in OpenStack.
You can find upstream collaboration activities on Bitergia by filtering on OpenStack.
|Project name||PTL||Project intention|
|Fault management and maintenance project to develop and realize needed implementations for the OPNFV reference platform.||List of upstream activities|
|Domino||Ulas C. Kozat, email@example.com||Template Distribution project to understand and develop needed functionality for template based service orchestration across multiple MANO components including VIM, VNFM, NFVO and SDN Controllers.|
Cathy Zhang firstname.lastname@example.org
Louis Fourie email@example.com
|OpenStack project that provides Service Function Chaining functionality for Neutron. This is an abstract API that allows an Orchestrator to create SFCs composed of a service path of VNFs (SFs). Each SF is represented as a pair of Neutron ports (ingress and egress). Port-pair-groups allow scale-in and scale-out operations for a group of SFs of similar function. This project was completed in the Mitaka release and there is ongoing enhancement work in the Newton cycle.|
|Functional Testing project. We reuse Rally and Tempest projects to perform tests. Rally is used to run Rally_sanity and start Tempest_smoke ((part of scenario validation), as well as Tempest_full or Rally_full (qualification).|
|This project aims to identify the gaps of upgrading OPNFV infrastructure without end-user noticeable service outage. The OPNFV infrastructure includes OpenStack and other upstream projects. By now, OPNFV have various installer projects to match different deployment scenarios. Ideally, Escalator will try to reuse the capabilities of them.|
|Promise is resource reservation and management project to identify NFV related requirements and realize resource reservation for future usage by capacity management of resource pools regarding compute, network and storage.|