OpenStack正逐渐被接受为企业级框架，用于自动化数据中心基础设施，并使企业能够运营各种各样的应用程序和服务。
2010年，该平台作为托管服务提供商Rackspace和NASA的联合项目出现在市场上。目前，它已经发展成为迄今为止最大的开放源码项目之一，其版本发布由OpenStack社区一年两次的会议推动，每次会议一般会公布下一个版本的优先事项。
市场研究表明，越来越多的企业OpenStack部署正在从试点项目（测试和开发平台）转向全面的生产状态，但还有一些待解决的问题——其中最主要的是确保在升级到最新版本时能平滑更新构成OpenStack的无数组件。OpenStack早期版本的升级总是有问题的，部分原因是那时候大部分开发工作侧重于保证其作为IaaS平台充分运行所需的功能。
早期采用者经常发现自己面临着难以置信的选择——要么在安装新代码的同时将OpenStack基础设施脱机，要么简单地将工作负载迁移到基于新代码的、完全独立的部署。这样的升级使得整个原有的平台在升级过程中需要花费大量时间中断业务，并升级相关软件包，并考虑软件包的相互依赖问题。在升级完成后，还需要经过大量的测试，确保不会影响其他原有的OpenStack组件，这样的升级经常使得用户“苦不堪言”。
而随着OpenStack社区的努力和产品的进步，和运维人员素质的提高，升级变得越来越可控，对业务的影响也变得更小了。特别是OpenStack产品在推出Kolla容器化部署后，由于容器的特性，可以使得每个组件可以解耦，对每个组件可以实现“原子化”的升级，令之前被一直诟病的升级问题变得易于处理。
较新的OpenStack版本，例如今年早些时候公布的Queen版本，更侧重于稳定性和可靠性，强调所有模块在升级时尽可能接近零停机时间。OpenStack社区也在通过对产品的不断提高功能性和稳定性，吸引用户来升级Openstack产品，也使得用户有兴趣升级已经部署在机房并且运行着的OpenStack。
然而，最新用户调查结果显示，有一半以上的OpenStack用户仍然运行着比最新版本老两个以上版本的平台。这意味着按照OpenStack官方的生命周期，这些用户的版本“不受支持”。打包和分发OpenStack构建的公司通常会提供更长时间（通常是三到五年）的商业支持。更重要的是，这可能意味着他们正在使用自发布以来就被认为具有安全漏洞和问题的OpenStack软件模块。
Openstack迭代很快，半年一次的更新往往会引入新的特性，及原有功能的完善。每个新版本都包含了大量的新特性以及性能稳定性的提升。
版本升级成为了一个不可避免的问题。由于openstack升级的复杂性许多公司和团队采用直接迁移至新版本云的方案，这是不失为一种可行的方案。
在某些情况下，升级OpenStack也意味着更新操作系统层， OpenStack的价值主张在很大程度上围绕着它很容易定制和高度可插拔的。OpenStack的一个优点在于它有一套全面的应用程序编程接口（API）服务，可以将不同的存储技术和不同的网络技术插入其中，并且围绕OpenStack和发行版有一个非常健康的生态系统。
实际上，“纯净的”OpenStack （即未经过定制化修改的原版OpenStack）并不难升级，因为每个OpenStack版本都是为无缝滚动更新（rollover）设计的，并经受大量的社区测试，确保升级过程尽可能顺畅无阻。在升级过程中，应该尽量减少生产环境的中断时间，因此需要优化升级过程，平滑升级。
从软件的进化的原则来说，在不断的bug修复过程中，才能提高软件产品的高可用性和鲁棒性，从早期版本到最新版本过程中，中间有多个大版本的进步，那么OpenStack不论是从功能性、易用性或者是从稳定性来说都是有了质变的提升，在不断修复bug的同时，社区的开发人员也从用户反馈的问题进行思考，而不是脱离实际用户。另外，社区也建议，使用比最新一版（Rocky）更低一级的版本（Queens）版本，这样即增加了社区的功能和稳定性，也降低了最新版本可能存在的风险。
OpenStack的产品每个版本都有新的项目加入，特别是社区实行了big tent策略之后，新的项目更是层出不穷，特别是新的项目如cinder multi-attach解决了共享存储的问题、cyborg对GPU有了更好的支持、也引进了Plecement API，给用户更好的可见性、cellv2模块支撑了更大的部署规模、octavia模块提供了一种全新的解决LB的思路、 keystone增加了多因素身份验证规则提高了云平台的安全性、界面上也把各个版本增加的功能体现在Horizon组件上、容器化也新增了kuryr和zun等组件来融合容器平台、OpenStack-Helm用于在Kubernetes之上管理 OpenStack的生命周期……还有很多精彩的新增功能来契合用户的痛点。
由于一些Vmware厂商和支持在裸机上直接部署容器的厂商的竞争，一些报道为了夸大OpenStack的缺点，因此可能用了一些修饰手法，从OpenStack社区开发人员“大量减少”或者是bug数“指数级增加”，都是比较片面的说法。从Mikata版本到Queens版本OpenStack社区的resolved bug数目来看，每个组件都有一些不同程度的增加和减少，而不是单纯的bug数量增加，更不是“指数性”增加。
OpenStack 是软件，是软件就会有 bug。 OpenStack 包含了很多组件，结构很松散，每个组件可以单独更新，只要保证各个组件都属于同一个大版本（比如 kilo, liberty）就不会有问题。在旧版本遇到了 bug，如果社区已经有 fix，只需要更新包含该 fix 的组件就可以了，其他组件保持不变。
6.1高效性。升级完成后，具备高效性。这一目标主要体现在：一是资源，时间资源、空间资源的高效利用，充分挖掘服务器的可利用价值，由于新的组件具备了资源占用更少、计算更加高效的特性，满足了升级的高效性；二是操作，OpenStack升级为用户提供便捷式操作，在原有功能基础上提供程序修改、软件组装、指令调整等新型功能。
6.2经济性。一项新软件产品成功研发需消耗大量的人力、物力、财力。从成本耗资角度考虑，新软件产品需符合持久应用的标准。而OpenStack借助了社区的力量，不需要在OpenStack软件开发上投入，使得产品的升级不需要耗费太多的成本，创造了良好的经济收益。而且社区一年发布2个版本，因此不会导致更新非常频繁。
6.3安全性。OpenStack产品升级配备了更高的安全防御功能，对常见的功能缺陷及时补充改进，增强云产品抗***的能力。如：用户认证开启了更强的安全防御功能，对网络的安全协议有了更好的支持，从而提高了软件工程系统的抗侵袭性能。
6.4稳定性。由于OpenStack社区具有庞大的开发者，而代码质量良莠不齐，每个版本都有很多明显或者不明显的Bug，那么在升级过程中，可以将已知的Bug进行修复，提高了OpenStack云产品的稳定性，以免在生产中发现问题，导致更大的损失。也符合软件升级螺旋式上升的特性。
6.5松耦合性。松耦合性是升级的一个重要目标，极大的降低了升级的成本投入，由于OpenStack组件都是松耦合的特点，只需要更改一个模块即可，实现合理的“即插即用”可以实现单一组件的升级，而不必对OpenStack云产品做大的更改。缩短了重新编程消耗的时间，这是升级的必然趋势，提高了软件产品工作的效率，缩短了重新编译时间，也更符合无痛升级的特点。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
