====== OPNFV OpenStack community page ====== This page is maintained by OPNFV and OpenStack community members. Rather than establish a project for OpenStack the OPNFV community has agreed to work on establishing focus community groups where we will describe community engagement practices, identify community leaders, manage our contributions toward those communities and generally get ourselves organised well enough to be a benefit, rather than a burden, to our source communities. ==== OpenStack and OPNFV projects and contacts ==== This [[https://docs.google.com/document/d/1JxXsQpIZ7eiYgWLqxPjLs3jAbvb3I_gGf2qhyxMOHaw/edit?usp=sharing|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. ==== OPNFV related blueprints ==== To facilitate the work of developers submitting blueprints to OpenStack, we have instituted a process for [[:requirements_projects|requirements projects]] which consists of the following: - Projects first create an OPNFV requirement document in Markdown in the project repository: ''repository/requirements/reference_document.rst'' - this document should describe the goal at a high level for OPNFV consumers - A requirement will result in one or more blueprints for a project which should be drafted (one blueprint per file) in ''repository/design_docs/reference_document.rst'' - These files should be proposed for review in [[http://gerrit.opnfv.org|OPNFV's Gerrit]], and should follow the OpenStack project's template file ([[https://github.com/openstack/ceilometer-specs/blob/master/specs/template.rst|example for Ceilometer]]) - After a successful community sanity check, verifying that the spec has sufficient implementation details and conforms with the minimum expectations of an OpenStack blueprint, the blueprint should be proposed to the upstream project. Proposal is by creation of a Gerrit patch against the "specs" repository of the OpenStack project ([[https://github.com/openstack/ceilometer-specs|Ceilometer specs]] and [[https://review.openstack.org/#/c/142867/|sample Ceilometer blueprint review]]) - Community comments are to be expected on a blueprint, and multiple revisions may be required upstream before the spec proposal will be merged The table below is a summary of the currently in-flight blueprints for OpenStack Mitaka. **Regularly updated.** Blueprint status can be "Work in progress" (blueprint being actively edited), "Under review" (blueprint is final and submitted for review), "Approved" (approved for inclusion, development work not yet started), "In development", "Completed" (work accepted upstream), "Rejected" (not approved for inclusion), "Deferred" (to be submitted for next release). If you have a blueprint which you would like reviewed, email to schedule a review on the weekly technical review call. ^ OpenStack Project ^ Blueprint name ^ Blueprint URL ^ OPNFV project driving ^ Lead contributor ^ Developer ^ Status | | | Ceilometer | Add independent alarm report mechanism | https://blueprints.launchpad.net/ceilometer/+spec/add-independent-alarm-mechanism | [[:high_availability_for_opnfv|HA for OPNFV]] | Zhang Shaoman | | **Abandoned (Liberty)** in favour of Monasca approach | | | ::: | Event Alarm Evaluator | https://blueprints.launchpad.net/ceilometer/+spec/event-alarm-evaluator | [[:doctor|Doctor]] | Ryota Mibu | Ryota Mibu | **Completed (Liberty)** | | | Nova | New nova API call to mark nova-compute down | https://blueprints.launchpad.net/nova/+spec/mark-host-down | [[:doctor|Doctor]] | Tomi Juvonen | Roman Dobosz | **Completed (Liberty)** | | | ::: | Support forcing service down | https://blueprints.launchpad.net/python-novaclient/+spec/support-force-down-service | [[:doctor|Doctor]] | Tomi Juvonen | Carlos Goncalves | **Completed (Liberty)** | | ::: | Get valid server state | https://blueprints.launchpad.net/nova/+spec/get-valid-server-state | [[:doctor|Doctor]] | Tomi Juvonen | Tomi Juvonen | **Completed (Mitaka)** | | | ::: | Get servers filtered by host status | https://blueprints.launchpad.net/nova/+spec/servers-by-host-status | [[:doctor|Doctor]] | Tomi Juvonen | Tomi Juvonen | **In review (Newton)** | | | ::: | Add notification for service status change | https://blueprints.launchpad.net/nova/+spec/service-status-notification | [[:doctor|Doctor]] | Balazs Gibizer | Balazs Gibizer | **Completed (Mitaka)** | | | ::: | (VNF_Geo_site_redundancy)Expose quiesce unquiesce api | https://blueprints.launchpad.net/nova/+spec/expose-quiesce-unquiesce-api | [[:multisite|Multisite]] | Chaoyi Huang | Zhenyu Zheng | **In development (Mitaka)** | | | Congress | | [[https://etherpad.opnfv.org/p/copper_bps|Event-Driven Policy Engine]] | [[:copper|Copper]] | Bryan Sullivan | | roadmap (post-R1) | | | ::: | | [[https://etherpad.opnfv.org/p/copper_bps|Data Source Extensions]] | [[:copper|Copper]] | Bryan Sullivan | | roadmap (post-R1) | | | Keystone | (multisite identity service management)Can't specify identity endpoint for token validation among several keystone servers in keystonemiddleware | https://bugs.launchpad.net/keystone/+bug/1488347 | [[:requirements_projects/multisite|Multisite]], [[:high_availability_for_opnfv|HA for OPNFV]] | Chaoyi Huang / Hans Feldt | | **Completed (Liberty) ([[https://review.openstack.org/#/c/216579/|Bug # 1405717]])** | | | ::: | OpenStack Hierarchical Administrative Framework | https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary | [[:collaborative_development_projects/oonosfw|ONOSFW]] | Prakash Ramchandran | | **Stalled** | | | Cinder | Add pagination query support for cinder snapshots/backup in a large scale system | https://blueprints.launchpad.net/cinder/+spec/snapshots-and-bakcup-support-pagination-query | [[:multisite|Multisite]] | Chi Zhang | | **Completed (Liberty)** | | | ::: | Using Change-Since Filter for Resource Query based on a specified time period for better sync in a large scale system | https://blueprints.launchpad.net/cinder/+spec/resource-change-since-filter | [[:multisite|Multisite]] | Zhiyuan Cai | | **Stalled** | | | ::: | (VNF_Geo_site_redundancy)Get replicated volume ref for DR | https://blueprints.launchpad.net/cinder/+spec/get-replica-volume-ref-for-dr | [[:multisite|Multisite]] | Wang Hao | | Work In Progress | | | ::: | new cinder API call to mark cinder-volume down | https://blueprints.launchpad.net/cinder/+spec/mark-services-down | [[:doctor|Doctor]] | Wenjuan Dong | | Work In Progress | | | ::: | Support forcing service down (CLI) | https://blueprints.launchpad.net/python-cinderclient/+spec/mark-service-down-cli | [[:doctor|Doctor]] | Wenjuan Dong | | Work In Progress | | | Heat-Translator | Implement new Networking feature in TOSCA | https://blueprints.launchpad.net/heat-translator/+spec/tosca-networking | [[:parser| Parser]] | Simeon Monov | | **Completed (Liberty)** | | | Neutron | OpenStack Service Chaining Framework | https://blueprints.launchpad.net/neutron/+spec/openstack-service-chain-framework | [[:requirements_projects/openstack_based_vnf_forwarding_graph|VNFFG]] | Cathy Zhang | | **Superseded ([[http://docs.openstack.org/developer/networking-sfc/|networking-sfc]] and/or [[https://wiki.openstack.org/wiki/Tacker|Tacker]])** | | | ::: | Allow admin to mark agents down | https://bugs.launchpad.net/neutron/+bug/1513144 | [[:doctor|Doctor]] | Carlos Goncalves | Carlos Goncalves | **Stalled (Incomplete)** | | | ::: | (VNF High Availability across VIM)ml2 cross backends extension spec | https://bugs.launchpad.net/neutron/+bug/1486882 | [[:multisite|Multisite]] | Shi Hanzhang | Shi Hanzhang | Work In Progress | | ==== OpenStack blueprint processes ==== Relevant process pages: * [[http://docs.openstack.org/project-team-guide|Project Team Guide including Release Management]] * [[https://wiki.openstack.org/wiki/Blueprints|Blueprint documentation]] * [[https://wiki.openstack.org/wiki/Mitaka_Release_Schedule|Mitaka release cycle]] * [[http://git.openstack.org/cgit/openstack/nova-specs/plain/specs/mitaka-template.rst|Nova Mitaka blueprint template]] A good blueprint has the following characteristics: * Explains the context of the blueprint - the high level use-case which requires the feature * Explains the feature request in a generic, non-NFV-specific manner * Provides some specification details on how the feature will be implemented * Uses the project's spec template (located in specs/template.rst of the project "specs" repo, typically) This provides the material for an informed, useful discussion upstream of the feature and whether the proposed approach is the best way to accomplish the high level goal. It is possible to get code into OpenStack without going through the Blueprint process by submitting a patch for review directly, but it does not make it easier to get the code accepted. Blueprints should be discussed and reviewed online in advance of Tokyo, and advocated for the design summit working sessions, to ensure they are included in scope for Mitaka. Blueprints proposed after the Tokyo Summit are not eliminated, but will have a hard time being approved for Mitaka. As a general rule of thumb, the earlier in the cycle you engage with the project teams, the more time you have for features and fixes to land in the release. Make sure that code starts coming in as soon as the spec is approved, as there are cases where time is spent on specs and then code shows up too late to be reviewed in time anyway. Some additional links on successfully shepherding blueprints through review: * [[http://robhirschfeld.com/2012/09/28/balastic-release/|Rob Hirschfeld's description of the release cycle]] * A presentation from Hong Kong on [[https://www.youtube.com/watch?v=E8hV-zDoEqI|navigating the blueprint process]] ==== OpenStack release management ==== From the Project Team Guide: * OpenStack deliverables are released in various ways and on different time-based or feature-based schedules * What binds them all is a common 6-month development cycle. * Design Summits are events held at the beginning of a development cycle, every 6 months. * Midcycle sprints (also named midcycle meetups) are optional project team gatherings that happen between Design Summits. * The development cycles follow a repeating pattern, which is described in general terms in the Typical Development Cycle Schedule of the Project Team Guide, Release Management section. Key dates for Mitaka, with emphasis on Nova; [[http://docs.openstack.org/releases/schedules/mitaka.html|consolidated cross-project schedule.]] All projects follow the Mitaka release schedule except Nova and Cinder, which are listed under Project-specific events. * Oct 15: [[https://www.openstack.org/software/liberty/|Liberty release]] * Week of Oct 26: Mitaka Design Summit (Tokyo) * Dec 1-3: mitaka-1 milestone * Dec 3: Nova spec freeze * Jan 19-21: mitaka-2 milestone * Jan 21: Nova non-priority feature freeze * Jan 26-28: Nova mid-cycle (TBC) * Feb 25: FinalLibraryRelease and feature proposal freeze * Mar 1-3: mitaka-3 milestone, soft feature, string and dependency freeze * Mar 14-18: Mitaka Release Candidate 1 target, hard freeze * Mar 28-Apr 1: Final Release Candidates & Intermediary releases * April 7: Mitaka release * Week of April 25: Newton Release Design Summit (Austin) * [[http://releases.openstack.org/newton/schedule.html|Newton Release Schedule]] There is no blueprint submission deadline for Neutron. Please visit [[http://docs.openstack.org/developer/neutron/policies/blueprints.html#blueprints-and-specs|for the Neutron blueprint and spec policy]]. The latest update from the Neutron PTL is found [[http://lists.openstack.org/pipermail/openstack-dev/2015-November/079816.html|here]]. ==== OpenStack project reform ==== With Liberty, OpenStack has implemented a Core and "Big Tent" project architecture. This enables a common definition of what constiutes "OpenStack" for interoperability, as well as opens the door to more projects. * [[https://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/|Thierry Carrez's pre-reform report]] outlines the objectives. * The revised project governance is documented [[http://governance.openstack.org/reference/index.html|here]]. ==== OPNFV and OpenStack requirements and development collaboration ==== After the first OPNFV Summit in November 2015, it became clear there would be tremendous value in a consistent means to present OPNFV blueprints and patches to the OpenStack projects. It's important to send your blueprints to , for adding to the table above. From there, * On a daily or weekly basis, a tool will scan the blueprints from this page * The tool will create a single Gerrit dashboard of all the patches associated with the open blueprints. * OpenStack Telco-focused community members will advocate the dashboard with the OpenStack project teams. * OPNFV blueprint submitters are expected to contribute code to complete the features according to the OpenStack schedule. Visit this page for more information on [[https://wiki.openstack.org/wiki/How_To_Contribute|How to Contribute]]. * OPNFV project Pharos provides community testing labs around the world. See locations, status and project assignments [[https://wiki.opnfv.org/pharos|here]]. ==== OpenStack Summits ==== === Tokyo'2015 === See the etherpad page for the [[https://etherpad.opnfv.org/p/openstack_tokyo_2015_bof|OPNFV BoF at the OpenStack Summit Tokyo 2015]]. [[https://etherpad.opnfv.org/p/Tokyo_Summit_Sessions_of_Interest|Tokyo 2015 OpenStack Summit sessions of interest]]