diff --git a/doc/openstack-ops/app_roadmaps.xml b/doc/openstack-ops/app_roadmaps.xml index 3f7f40d9..5748d646 100644 --- a/doc/openstack-ops/app_roadmaps.xml +++ b/doc/openstack-ops/app_roadmaps.xml @@ -14,23 +14,24 @@ Working with Roadmaps The good news: OpenStack has unprecedented transparency when it comes to providing information about what's coming up. The bad news: each release -moves very quickly. The purpose of this chapter/section is to highlight some of +moves very quickly. The purpose of this appendix is to highlight some of the useful pages to track, and take an educated guess at what is coming up in the Icehouse release and perhaps further afield. OpenStack follows a six month release cycle, typically releasing in April/May and October/November each year. At the start of each cycle, the community gathers in a single location for - a Design Summit. At the summit, the features for the - coming releases are discussed, prioritized and planned. - Here's an example release cycle with dates showing + a design summit. At the summit, the features for the + coming releases are discussed, prioritized, and planned. The + figure shows an example release cycle with dates showing milestone releases, code freeze, and string freeze dates - along with an example of when the Summit occurs. + along with an example of when the summit occurs. Milestones are interim releases within the cycle that are available as packages for download and testing. Code freeze is putting a stop to adding new features to the release. String freeze is putting a stop to changing any strings within the source code. - +
+ Release Cycle Diagram /> - +
Information Available to You @@ -64,8 +65,10 @@ the Icehouse release and perhaps further afield. >Under development, Release schedule - Due - Apr 17, 2013 + 2014.1 + Apr 17, 2014 Havana @@ -300,8 +303,7 @@ the Icehouse release and perhaps further afield. xlink:href="http://vmartinezdelacruz.com/how-to-work-with-blueprints-without-losing-your-mind/" >blog post about how to work with blueprints (http://vmartinezdelacruz.com/how-to-work-with-blueprints-without-losing-your-mind/) - for a developer intern's perspective, Victoria - Martínez. + the perspective of Victoria Martínez, a developer intern. The roadmap for the next release as it is developed can be seen at (https://blueprints.launchpad.net/nova), OpenStack Identity (keystone) Blueprints - (https://blueprints.launchpad.net/keystone) and release + (https://blueprints.launchpad.net/keystone), and release notes. - Aside from direct-to-blueprint pathway, there is another very + Aside from the direct-to-blueprint pathway, there is another very well-regarded mechanism to influence the development roadmap: the user survey. Found at http://openstack.org/user-survey, it allows you to provide @@ -329,16 +331,16 @@ the Icehouse release and perhaps further afield.
Aspects to Watch - You want to keep an eye on these areas improving within - OpenStack. The best ways to "watch" roadmaps for each + You want to keep an eye on the areas improving within + OpenStack. The best way to "watch" roadmaps for each project is to look at the blueprints that are being approved for work on milestone releases. You can also learn from PTL webinars that follow the OpenStack - Summits twice a year. + summits twice a year.
Driver Quality Improvements A major quality push has occurred across drivers - and plugins in Block Storage, Compute and + and plug-ins in Block Storage, Compute, and Networking. Particularly, developers of Compute and Networking drivers that require proprietary or hardware products are now required to provide @@ -349,12 +351,12 @@ the Icehouse release and perhaps further afield. Easier Upgrades One of the most requested features since OpenStack began (for components other than Object Storage, which tends to "just work"): easier upgrades. From Grizzly - onward (and significantly improved in Havana) internal messaging communication is + onward (and significantly improved in Havana), internal messaging communication is versioned, meaning services can theoretically drop back to backward-compatible - behaviour. This allows you to run later versions of some components, while keeping + behavior. This allows you to run later versions of some components, while keeping older versions of others. In addition, a lot of focus has been placed on database migrations. These are now - better managed, including the use of the Turbo Hipster tool during development - + better managed, including the use of the Turbo Hipster tool, which tests database migration performance on copies of real-world user databases. These changes have facilitated the first proper OpenStack upgrade guide, found in @@ -363,22 +365,22 @@ the Icehouse release and perhaps further afield.
Deprecation of Nova Network - With the introduction of the full software defined + With the introduction of the full software-defined networking stack provided by OpenStack - Networking (Neutron) in the Folsom release, + Networking (neutron) in the Folsom release, development effort on the initial networking - code that remains part of the compute component - has gradually reduced. While many still use + code that remains part of the Compute component + has gradually lessened. While many still use nova-network in production, there has been a - long term plan to remove the code in favour of + long-term plan to remove the code in favour of the more flexible and full-featured OpenStack Networking. An attempt was made to deprecate nova-network during the Havana release, which was aborted due to the lack of equivalent functionality (such as - the FlatDHCP multi_host High Availability mode + the FlatDHCP multi-host high availability mode mentioned in this guide), lack of a migration - path between versions, insufficient testing and + path between versions, insufficient testing, and simplicity when used for the more straightforward use cases nova-network traditionally supported. Though significant @@ -386,18 +388,18 @@ the Icehouse release and perhaps further afield. nova-network will not be deprecated in the Icehouse release. In addition, the Program Technical Lead of the Compute project has - indicated that to a limited degree, patches to + indicated that, to a limited degree, patches to nova-network will now again begin to be accepted. This leaves you with an important point of decision when designing your cloud. OpenStack Networking is robust enough to use with a small number of limitations (IPv6 support, performance - issues in some scenarios), + issues in some scenarios) and provides many more features than nova-network. However, if you do not have the more complex use cases that can benefit from - fuller software defined networking capabilities, + fuller software-defined networking capabilities, or are uncomfortable with the new concepts introduced, nova-network may continue to be a viable option for the next 12 to 18 months. @@ -407,61 +409,61 @@ the Icehouse release and perhaps further afield. to delay the upgrade for this period of time. However, each release of OpenStack brings significant new innovation, and regardless of - your usage of networking methodology it is + your use of networking methodology, it is likely best to begin planning for an upgrade - within a reasonable time frame of each release. + within a reasonable timeframe of each release. As mentioned, there's currently no way to cleanly migrate from - nova-network to Neutron. We recommend that you keep a migration + nova-network to neutron. We recommend that you keep a migration in mind and what that process might involve for when a proper migration path is released. If you must upgrade, please be aware - both service and instance downtime is likely unavoidable. + that both service and instance downtime is likely unavoidable.
- Replacement of Open vSwitch plugin with Modular Layer + <title>Replacement of Open vSwitch Plug-in with Modular Layer 2 - The Modular Layer 2 plugin is a framework allowing + The Modular Layer 2 plug-in is a framework allowing OpenStack Networking to simultaneously utilize the - variety of layer 2 networking technologies found in + variety of layer-2 networking technologies found in complex real-world data centers. It currently works with the existing Open vSwitch, Linux Bridge, and Hyper-V L2 - agents, and is intended to replace and deprecate the - monolithic plugins associated with those L2 + agents and is intended to replace and deprecate the + monolithic plug-ins associated with those L2 agents.
Compute V3 API - The 3rd version of the Compute API was broadly + The third version of the Compute API was broadly discussed and worked on during the Havana and Icehouse release cycles. Current discussions indicate that the V2 API will remain for many releases, but this is a great time to evaluate the Compute API and provide comments while it is being defined. Of particular note is the decision that the V3 - API will not support XML messages - being JSON only. This was + API will not support XML messages—being JSON only. This was based on the poor testing of existing XML responses in the V2 - API, and lack of effort to continue to develop and maintain an + API and the lack of effort to continue to develop and maintain an entire second response type. Feedback on this and any such change is welcome by responding to the user survey.
OpenStack on OpenStack (TripleO) - Continues to improve and you may consider using it for greenfield + This project continues to improve and you may consider using it for greenfield deployments.
- Hadoop-as-a-Service (Savanna for now with a rename coming) - A much-requested answer to Big Data problems, a dedicated + Hadoop-as-a-Service (Sahara) + A much-requested answer to big data problems, a dedicated team has been making solid progress on a Hadoop-as-a-Service project.
- Bare-metal Deployment (Ironic) - Though Bare-metal deployment has been widely lauded, and + Bare-Metal Deployment (Ironic) + Though bare-metal deployment has been widely lauded, and development continues, the project to replace the Compute bare-metal driver will not graduate in Icehouse. A particular blueprint to follow is - Migration path from Nova's BM driver, which tracks the ability - to move to the new project from an existing bare metal deployment. + Migration Path from Nova's BM Driver, which tracks the ability + to move to the new project from an existing bare-metal deployment.
Database as a Service (Trove) @@ -469,14 +471,14 @@ the Icehouse release and perhaps further afield. tool in development for some time, and we will finally see the first integrated release of it in Icehouse. Initially, it will only support MySQL, with further - options available in Juno onwards, but it should be able - to deploy database servers out-of-the-box in a highly + options available in Juno onward, but it should be able + to deploy database servers out of the box in a highly available way from this release.
Messaging as a Service (Marconi) A service to provide queues of messages and notifications - has entered 'incubation', meaning if the upcoming + has entered 'incubation,' meaning if the upcoming development cycles are successful, it will be released in Juno.
@@ -484,20 +486,20 @@ the Icehouse release and perhaps further afield. Scheduler Improvements Both Compute and Block Storage rely on schedulers to determine where to place virtual machines or volumes. - While in Havana the Compute scheduler underwent - significant improvement, in Icehouse the scheduler in + In Havana, the Compute scheduler underwent + significant improvement, while in Icehouse the scheduler in Block Storage is slated for a boost. Further down the - track, an effort started this cycle which aims to create - a holistic scheduler covering both, will come to + track, an effort started this cycle that aims to create + a holistic scheduler covering both will come to fruition.
Block Storage Improvements - The team discussed many areas of work at the Icehouse summit + The team discussed many areas of work at the Icehouse summit, including volume migration support, Ceph integration, and access control for volumes.
- Toward a 'Proper' Python SDK + Toward a Python SDK Though many successfully use the various python-*client code as an effective SDK for interacting with OpenStack, consistency between the projects and documentation availability waxes and wanes. To combat @@ -506,7 +508,7 @@ the Icehouse release and perhaps further afield. efforts in OpenStack have a checkered history, such as the unified client project having several false starts. However, - the early signs for the SDK project are promising and we expect to see + the early signs for the SDK project are promising, and we expect to see results during the Juno cycle.