OpenStack 2018 年终盘点

目录

文章目录

• 目录
• 前言
• OpenStack 一年来的成长
• Nova
• Cinder
• Neutron
• Ironic
• Cyborg
• Octavia
• Kolla
• Magnum
• Zun
• Kuryr
• 从 OpenStack 到 OpenInfra

前言

这是最好的时代，也是最坏的时代 — — 查尔斯·约翰·赫芬姆·狄更斯《双城记》

年关将至，闲暇之余，回顾我与 OpenStack 的 2018。

NOTE：本文内容仅做为我的看法，与公司及合做伙伴无关。

OpenStack 一年来的成长

首先，不妨从 OpenStack Releases Notes 回顾一下今年社区开发者们做出了哪些努力，下面列举一些我我的而言比较惊喜的新功能。

https://releases.openstack.org/rocky/
https://releases.openstack.org/queens/

Nova

• Added support for vGPUs. Experimental feature with some caveats, but admins can now define flavors that request vGPU resources.

GPU（图形处理单元）的 “加速” 能力在科学计算、图形处理密集型计算、机器学习、深度学习、人工智能等高性能计算领域有着普遍的应用，Nova Libvirt Driver 支持 vGPU 无疑是为了知足这方面的市场需求。管理员能够经过 Flavors 来定义 vGPU 的资源特性与分辨率。

nova flavor-key <flavor-id> set resources:VGPU=1

我认为 Nova vGPUs Support 是一个挺具备标志性的新功能，能够看出社区有很是积极的去适应新的技术潮流。

vGPU 的资源管理依旧是交由 OpenStack Placement 负责。Placement 是最近才从 Nova Placement API 孵化出来的新 Repo，并计划在 Stein 版本中成为独立项目，指望能最终代替 nova-scheduler service。随着 OpenStack 的定义被社区进一步升级为「一个开源基础设施集成引擎」，意味 OpenStack 的资源系统将会由更多外部（第三方）资源类型构成（e.g. 外部存储资源、外部网络资源、各种 PCI 设备）。因此，当资源类型和提供者变得多样时，就会需求一种高度抽象且简单统一的管理方法，让用户和代码可以便捷的使用、管理整个 OpenStack 的系统资源，这就是 Placement（布局）。

• The performance of listing instances across a multi-cell cells v2 deployment has been improved and the results are now merge sorted.
• Rescheduling during a server create or resize operation is now supported in a split-MQ multi-cell cells v2 deployment.
• Operators can now disable a cell to make sure no new instances are scheduled there. This is useful for operators to introduce new cells to the deployment and for maintenance of existing cells.

今年对 Nova Cell 的支持力度依然很大，主要改进了 Multi-Cell 的性能和可操做性，这让 OpenStack 拥有了更增强大的弹性和可扩展性，使 OpenStack 适用于更大的集群规模。

• Traits-based scheduling is now available for the ironic compute driver. For more details, see the ironic docs for scheduling based on traits.

Ironic 支持基于 Traits（特征）的调度方式，该功能一样由 OpenStack Placement 实现的 Resource traits 支持，是 Nova 支持基于 Traits 对 Compute Node 进行调度的延伸功能。Placement resource traits 是一种灵活设计，相似 “标签”，用户能够创建 “标签云” 并决定为某个 Resource Provider 贴上 “标签”，是一种资源概括分类需求的辅助工具。

• The placement service now supports granular RBAC policy rules configuration.

Placement 支持 RBAC（角色访问控制）策略规则，是成为独立项目前的必要手续。我我的认为，OpenStack Placement 是很是值得关注的，它未来会逐步融汇到 OpenStack 操做的各个层面中。

Cinder

• Support for attaching a single Cinder volume to multile VM instances.

Cinder Multi-Attach 支持将同一个 Volume 挂载到多个不一样的 VM，这是一个让人期待已久的功能，由于讨论的时间实在是太长了。Multi-Attach 最直接的价值就是支撑核心业务数据盘的高可用冗余特性，好比说：一个 Volume 同时挂载在两个 VM 上，当 ACTIVE VM 失联时，能够由另外的 PASSIVE VM 继续访问（RO、R/W）这个卷。多台 VM 共享一个 Volume，在集群场景中带来了不少便利，相似的功能一直是云环境中最受欢迎的功能之一。

• Support for creating a volume from a backup.
• Improved user experience when recovering from storage system failures.
• Security improvements enabled when creating volumes from signed images.
• Numerous improvements that give administrators greater control over the placement of volumes.
• Improved backup functionality and performance.

对于 Cinder，我一直比较关注它「Volume Backup and DR」的进展，这与我曾经有过云备份与容灾恢复的开发经历有关。如今 Cinder 已经支持了从备份建立新卷，并且经过优化 cinder-backup service 使用多处理器来提高了备份的性能。另外一个值得高兴的是，如今能够经过 cinder-manage 指令来执行故障转移以及故障恢复，避免用户直接操做数据库的必要。能够看出 Cinder 在提高用户体验上也花费了很多精力。

另外，今年的丹佛 OpenStack PTG，Cinder 团队还讨论了关于 Cinder 项目独立的议题，使 Cinder 成为在没有 Keystone 或 Nova 的场景中（e.g. K8s CSI）仍能够独立部署并提供服务价值的项目。这个就比较有意思了，由于这样的议题在社区中一直都颇具争议，有一部分社区开发者会对这些但愿 “脱离” OpenStack 体系的项目持有抵触心理，他们认为只有跟 OpenStack 结合得更加紧密才能产生 1+1 > 2 的效益。但随着社区提倡了所谓的 “可组合性” 项目生态协做方式，的确有感受到讨论这个话题的团队在逐渐增多。对此，我是持保留意见的，这个咱们后面再聊。

Neutron

• OVN DNS support. ovn-controller will respond to DNS queries locally on each compute node.
• OVN distributed Floating IP support.
• OVN L3 HA support for gateway routers. Now networking-ovn makes use of the OVN embedded mechanism for L3 high availability. It will be automatically used for any router as soon as more than one gateway node is available.
• OVN supports IPv6 Router solicitation and IPv6 Periodic router advertisement support.
• OVN supports binding SR-IOV ports on OVS > 2.8 and kernel >=4.8
• Support migration from an existing ML2OVS TripleO deployment to ML2OVN TripleO deployment.

Neutron 项目的人气一直都很高，更新的内容天然也多，我主要仍是关注 OVN 的更新动态。OVN 是 OpenvSwitch 的 SDN 控制器，做为 OVS 的控制平面，它对于运行平台没有特殊的要求，只要可以运行 OVS，就能够平滑的运行 OVN。因此 OVN 对于 OpenStack 也有很是优秀的的兼容性，Neutron 只须要添加一个 Plugin 来配置 OVN 便可实现集成。采用 OVN 会为 Neutron 带来一些便利，好比说：OVN 原生的网络功能能够替代 Neutron 的 OVS agent、L3 agent、 DHCP agent 以及 DVR，让 Neutron 的部署架构变得更加轻巧，同时 OVN 还提供了更加高的 L3 转发性能。

• OVN NorthBound backend database consistency mechanism, multiple workers are now completely safe to access the backend database, and any inconsistency generated by the backend not being available is quickly detected and corrected by a periodic job

惋惜的是因为 OVS DB 不是相似 MySQL 一类的 ACID 事务型数据库，而是一个 JSON-Base 的文件数据库，记录的都是一些执行命令，每次有更新或初始化都会逐条地去执行这些的指令，这种实现的并发处理性能显然是不行的。因此 OVN 如今还只适用于小规模场景，社区有提议过把 OVS DB 换成 ETCD，但也不了了之。不过从 OVN 在 Neutron 更新列表中的比重来看，依旧挺值得关注。

• ML2 implements Quality of Service rate limits for floating IPs.

浮动 IP 也开始支持 Qos 了，Octavia 支持 VIP Qos 也得益于这个实现。

• Per TCP/UDP port forwarding on floating IP is supported. Operators can save the number of global IP addresses for floating IPs.

Port forwarding 是一个比较实用的功能，应用 iptables 规则映射，实现了 IP 复用的效果，有效的节省了浮动 IP 的浪费。是一个很省钱的功能。

Ironic

• Finished implementation of rescue mode. Users can repair instances, troubleshoot misconfigured nodes, lost SSH keys, etc.

Ironic rescue mode 类比 Nova 实现的 Rescue/Unrescue 虚拟机实例修复功能，经过指定的启动盘启动，进入 Rescue 模式以修复受损的系统盘，如今 Ironic 也支持经过这种方式来修复裸机实例。那些老丢失 SSH Keys 的云管们能够松一口气了。

• Added ability to manage BIOS settings, with driver support for iRMC and iLO hardware types.

BIOS 是物理硬件加载的第一个程序，负责执行硬件初始化，拥有不少可做为的配置选项。Ironic manage BIOS settings 为 iLO 和 iRMC 硬件类型提供 BIOS 设置管理界面可支持众多使用场景。好比说：配置电源管理、RAID、启用 SR-IOV 或 DPDK 等等，对于裸机云和 NFV 这类对硬件管理灵活性要求比较高的应用场景而言是一个很是友好的支持。

• Added a ramdisk deployment interface enabling high performance computing deployments to have diskless nodes.
• Added automatic recovery from power faults, removing a long standing headache for operators.

RAMDisk 支持在没有安装操做系统的裸金属设备上经过特定的引导方式将 ramdisk 运行在内存中为 ironic-python-agent 提供执行环境，以这种方式来控制 diskless（无磁盘节点）的裸金属硬件设备，是大规模高性能计算部署场景的经典需求。如今不只提供了 ramdisk deployment interface 并且还支持电源故障自动修复，这些对于裸机云来讲都是很是不错的加强。

• Added the ability to define groups of conductors and nodes, enabling operators to define specific failure or management domains.

Ironic Conductor 是 Ironic 的核心 Worker，每一个 Conductor 能够运行多个 Drivers，Conductor 经过这些 Drivers 在硬件设备上执行操做。Conductor Group 用于划分 Conductors，并将 Nodes 分配到 Conductor Group，以此来限制指定的 Conductors 对指定的 Nodes 拥有控制权。简单来讲这是一种划分故障域的手段，经过将物理位置相近的 Conductors 分为一组可以有效缩小网络分区，提高了安全和性能。

Ironic 在这一年还真是作了很多事情，全球峰会关于裸机云（Bare Metal Cloud）议题的热度也很高，这跟 Ironic 部署率逐年攀升的市场反馈是成正比的。我我的感受市场对裸机、虚拟机、容器三足鼎立的格局仍是比较认同的，如今有愈来愈多的企业愿意本身的云平台实现跨虚拟化，除了虚拟机以外，也开始直接在裸机上部署容器，这样的云架构会更加灵活。从 Ironic 发布的这些新功能来看，Ironic 团队的裸机云蓝图也愈来愈清晰了。

Cyborg

Cyborg 是一个新发布的项目，脱胎于电信领域，旨在为专用加速设备（e.g. GPU，FPGA，SoC，NVMe SSD）以及各种加速器实现（e.g. iNIC，IP-Sec，DPDK/SPDK，eBPF/XDP）提供通用的生命周期管理框架。

经过 Cyborg，用户能够发现、显示加速器分类列表，链接/分离加速器实例，安装/卸载相关驱动程序，在 NFV、人工智能等高性能计算应用场景有很大潜力。Cyborg 能够单独使用，也能够与 Nova 或 Ironic 结合使用。对于前者而言，Cyborg 是 OpenStack Placement 对加速资源管理的补充；对于后者而言，Cyborg 是 Ironic 对加速硬件设备管理的补充。

以往 Nova 经过 PciDevTracker 来统计 PCI 资源（e.g. SR-IOV 网卡）数据并结合 PciPassthroughFilter 来实现 PCI 资源的调度，缺少统一的 PCI 资源管理 API，而这正是 Placement 的历史使命。Placement 结合 Cyborg 的方案有利于解决加速设备资源统计与管理的问题。当用户须要建立一个 vGPU 虚拟机时，由 Nova 发起建立，由 Cyborg API 提供 GPU 设备管理，由 Placement API 负责调度、统筹 vGPU 资源，三者协同合做并最终经过 PCI-Passthrough 技术将 vGPU 挂载到虚拟机。

因此，我以为 Cyborg 项目的发布一样具备标志性，它会加速推动 OpenStack 在高性能计算场景的应用，是社区布局边缘计算、物联网、人工智能领域的直接反映。

Octavia

• The neutron-lbaas and neutron-lbaas-dashboard projects are now deprecated.
• Neutron-lbaas now includes a proxy plugin that forwards all API requests to the Octavia API.

Octavia 是 OpenStack 官方推荐的 LBaaS 解决方案，它比 Neutron-lbaas 具备更好的扩展性、高可用性和稳定的 API，是运营商级别的负载均衡器服务。Neutron-lbaas 已经被标记为废弃，但旧版本的 Neutron-lbaas 依旧能够经过 Proxy Plugin 的方式来调用 Octavia API。

• The initial release of the Octavia dashboard for Horizon includes significantly improved load balancer detail pages and workflows compared to the, now deprecated, neutron-lbaas-dashboard.
• Octavia dashboard details pages now automatically refresh the load balancer status.
• The Octavia OpenStack client plugin now supports quotas, load balancer QoS policies, load balancer failover, listener statistics, and filtering by load balancer ID.

Octavia 有专属的 Dashboard 和 CLI 操做入口，早期 Octavia 和 Neutron-lbaas 共用一套 UI，但具备 Octavia 特点的操做并不能体现出来。如今专门针对 Octavia 的 Dashboard 和 CLI 确定会带来更好的用户体验。

• Octavia now supports provider drivers, allowing third party load balancing drivers to be integrated with the Octavia v2 API.

Neutron-lbaas 实现了不少第三方负载均衡器的 Drivers 碍于时间和人力的问题迟迟没有迁移到 Octavia，实在很是惋惜。早前的用户只能选择使用 Octavia Amphorae LoadBalancer Provider 实现方式，如今 Octavia 的架构调整已经完成，能够支持集成第三方负载均衡器 Drivers 了。对于那些由于使用第三方负载均衡器（e.g. F5）致使没法升级至 Octavia 的用户而言，也是一个好消息。

• Pools can have backup members, also known as “sorry servers”, that respond when all of the members of a pool are not available.

Octavia Pool 支持设置 Backup Member，当 Pool 中全部的 Members 都失联时，将有 Backup Member 响应，进一步提高了 LB 可用性和服务体验。

• UDP protocol load balancing has been added to Octavia. This is useful for IoT use cases.

Octavia 开始支持 UDP 协议，UDP 协议常常被用于处理音频、视频数据流及其余实时应用中的传输层，知足了在物联网和边缘计算场景中的负载均衡需求。

Kolla

• Implement minimal downtime for keystone and cinder service

Kolla 已经能够支持 Keystone 和 Cinder 的最小停机时间的，这预设着 OpenStack 项目无缝升级的可行性，不管是对用户仍是对运维人员来讲都是一件极大的利好。

• Implement Ceph Bluestore deployment in kolla and kolla-ansible.
• Implement cephfs service
• Upgrade to ceph luminous

今年 Kolla 对 Ceph 的支持力度依旧很大，Ceph 如今已是全部 OpenStack 用户都会考虑的分布式存储方案。将 Ceph 和 OpenStack 一块儿打包部署相信会是一个很棒的用户爽点。

• Add almanach, certmonger, ceph-nfs, ptp, rsyslog, sensu and tripleo ui image
• Add vitrage ansible role
• Support deployment of prometheus, kafka and zookeeper via kolla-ansible.
• Added new docker images in kolla for logstash, monasca, prometheus, ravd, neutron-infoblox-ipam-driver and apache storm.

Kolla 实现的原子服务容器化结合 Kolla-ansible 来完成配置管理的自动化 OpenStack 部署方案，在通过了屡次大规模生产级别部署后，已经获得了业内普遍的承认。Kolla 如今已经成为了国内 OpenStack 用户首选的规模化部署方案，国内一直在为 Kolla 做出主要贡献的九州云实在是功不可没。

Magnum

Magnum 项目由 OpenStack Containers Team 开发并推出，旨在将容器编排引擎做为 OpenStack 的首类资源，异构兼容 Kubernetes，Mesos，Swarm 等容器管理平台，为 OpenStack 用户提供无缝的容器运行体验。经过 Magnum，你能够像建立虚拟机同样建立一个容器集群，透明的 COE（Container Orchestration Engine）部署及网络调整，开箱即用。借助于 OpenStack 服务，Magnum 还能够额外提供 COE 不具备的多租户认证鉴权和多租户网络隔离等功能。

• Add new label ‘cert_manager_api’ enabling the kubernetes certificate manager api.
• Add new labels ‘ingress_controller’ and ‘ingress_controller_role’ enabling the deployment of a Kubernetes Ingress Controller backend for clusters. Default for ‘ingress_controller’ is ‘’ (meaning no controller deployed), with possible values being ‘traefik’. Default for ‘ingress_controller_role’ is ‘ingress’.
• Update kubernetes dashboard to v1.8.3 which is compatible via kubectl proxy. Addionally, heapster is deployed as standalone deployemt and the user can enable a grafana-influx stack with the influx_grafana_dashboard_enabled label.
• Update k8s_fedora_atomic driver to the latest Fedora Atomic 27 release and run etcd and flanneld in system containers which are removed from the base OS.
• k8s_fedora_atomic clusters are deployed with RBAC support. Along with RBAC Node authorization is added so the appropriate certificates are generated.
• Embed certificates in kubernetes config file when issuing ‘cluster config’, instead of generating additional files with the certificates. This is now the default behavior. To get the old behavior and still generate cert files, pass –output-certs.
• Add ‘cloud_provider_enabled’ label for the k8s_fedora_atomic driver. Defaults to true. For specific kubernetes versions if ‘cinder’ is selected as a ‘volume_driver’, it is implied that the cloud provider will be enabled since they are combined.
• Update k8s_fedora_atomic driver to the latest Fedora Atomic 27 release and run etcd and flanneld in system containers which are removed from the base OS.

在 Kubernetes 稳坐容器编排平台老大地位同时，Magnum 今年的更新也主要围绕着它进行，并且还经过了 Kubernetes 社区承认的部署工具认证。若是你想经过 Kubernetes 来构建你的容器环境，那么使用 Magnum 在 OpenStack 上部署 Kubernetes 是一个不错的选择。由于安全性的问题，直接在裸机上部署 Kubernetes 不见得是一个使人放心的选择，经过 Magnum 则能够更加灵活的选择将 Kubernetes 部署到 “Nova” 或者 “Ironic” 上。

• In the OpenStack deployment with Octavia service enabled, the Octavia service should be used not only for master nodes high availability, but also for k8s LoadBalancer type service implementation as well.

值得一提的是，因为 Octavia Member 对象的代码实现是依附于 IP 而非 Instance 的，这样的设计使其可以适用于多种不一样的场景，而非仅限于只可以为 OpenStack Nova Instance 提供负载均衡服务。因此 Octavia 也能够为 Kubernetes 的 Pods 提供外层负载均衡服务。

Zun

熬了这么久的 Zun 项目，终于在今年发布了 1.0，紧接着在下半年发布了 2.0。Zun 是一个 OpenStack Container as a Service 项目，目标是经过与 Neutron、Cinder、Keystone、Kuryr 等等 OpenStack 项目协同合做以提供原生的容器管理服务。经过这种方式，将 OpenStack 原有的网络、存储以及身份鉴权等服务无缝的融入到容器技术体系，它容许用户无需管理服务器或集群便可快速地启动、运行容器，进而确保容器可以知足用户在安全与合规性方面的要求。

Zun 实际是 Nova Docker Driver 的替代方案，Nova Docker Driver 的缺点在于 Docker 容器和虚拟机始终没法实现彻底统一的抽象层，经过类虚拟机方式来操做容器，不免会丧失一部分优秀的容器特性，例如容器关联、端口映射等等。因此，简单来讲 Zun 就是独立于 Nova 以外的 Docker 容器部署调度框架。这本应该是 Magnum 的初衷，实现容器建立和生命周期管理，把容器做为 OpenStack 首类资源。但 Magnum 在发展的进程中已经演变成了 COEs 的部署调度管理项目，这就是 Zum 和 Magnum 的本质区别。

我我的认为 Zun 这个项目实际上是挺尴尬的，我一直以为把容器看成虚拟机来用根本就是一个天大的误会，没有编排的容器感受就缺乏了灵魂。但我是知道国内有些大企业在使用它的，因此我也很好奇 Zun 能够在怎样的应用场景中落地。拭目以待吧。

Kuryr

• Introduced port pools feature.
• Support for running in containers as K8s network addon.
• Introduced kuryr-daemon service.
• Introduced liveness and readiness probes for kuryr-controller.
• Added support for High Availability kuryr-controller in an Active/Passive model, enabling quick and
• transparent recovery in case kuryr-controller is lost.
• Added support for namespace isolation, lettting users isolate pods and services in different namespaces, implemented through security groups.
• Added support for multi-vif based on Kubernetes Network Custom Resource Definition De-facto Standard spec defined by the Network Plumbing Working Group, allowing multiple interfaces per pod.

Kuryr 的历史使命就是将容器网络与 OpenStack Neutron 对接，实现虚拟机实例、容器、外部网络三者互通。随着容器网络发展出现的分歧，Kuryr 也相应的有两个分支：kuryr-libnetwork（CNM）和 kuryr-kubernetes（CNI）。从更新列表能够看出，今年的 Kuryr 团队彷佛更倾向于以推动 kuryr-kubernetes 为主。使用 Kuryr-Kubernetes 能够讓你的 OpenStack VM 與 Kubernetes Pods 运行在同一个网络中，並且能夠使用 Neutron 的 L3 与 Security Group 來实现网络路由以及隔离特定的 Ports。

• Added support for health checks of the CNI daemon, letting users confirm the CNI daemon’s functionality and set limits on resources like memory, improving both stability and performance and for it to be marked as unhealthy if needed.

Kuryr CNI 根据 Kuryr Controller 分配的资源将网络绑定到特定的 Pods 上，如今增长了一个 CNI Daemon 会有效提高运维 Kubernetes 的可扩展性。

• Added native route support enabling L7 routing via Octavia Amphorae instead of iptables, providing a more direct routing for load balancers and services.

随着 Octavia 的成熟，愈来愈多的项目有意借助于 Octavia Amphorae 的网络连通性，我我的也认为 Amphorae 带来的这种打通网络的能力是一个颇有想象空间的实现方式。

除了网络以外，Kuryr 还但愿能够成为容器与 OpenStack 之间的 Storage Bridge，支持容器访问 Cinder 块存储以及 Manila 共享存储服务。Kuryr 是 OpenStack 与容器结合的关键节点，值得关注。

从 OpenStack 到 OpenInfra

之因此花这么长时间来整理今年两个新版本 Queens 和 Rocky 的 Release Note，是由于这些都是 OpenStack 发展方向最直接体现。从宏观角度看，我是这么来总结的。

• Pike 版的主导的是下降运维成本
• Queens 版主导的是实现更好的易用性和操做体验
• Rocky 版主导的是业务场景融合

以前有人说 PQR 三个版本不会有太明显的突变，依旧会以稳定性为主。我不赞同，经过上面的整理，咱们能够感觉到 OpenStack 这一年在大规模部署、快速升级、高性能计算、硬件加速、裸机云、拥抱容器以及资源管理整合方面都有不错的表现，这些努力显然是为了迎接 5G 时代的物联网、边缘计算、电信 NFV 以及人工智能领域的业务负载。OpenStack 社区依旧在紧贴用户需求，追随技术潮流。正如 OpenStack 基金会首席运营官 Mark Collier 所言：“咱们如今看到的市场，是人们但愿用云作更多的事情，如机器学习、人工智能和容器等新的工做负载。”

去年我在《从 2017 OpenStack Days China 看国内云计算的发展示状》一文中提到：国内的 OpenStack 私有云已经正式迈入成熟阶段。成熟的标志就是用户冲突从 “如何作云” 向 “如何用云” 的偏移；用户的部署案例从测试环境向生产环境转移；用户托付给 OpenStack 的工做负载从非核心业务向核心业务迁移。17 年是 OpenStack 遍地开花的一年，那么 18 年就应该是纵深挖掘行业价值、业务融合、市场更加细分的一年。简单总结一下今年 OpenStack 给我感觉最深的变化 —— 从稳定性中解放，在应用场景中深化。

随着整个云计算行业的飞速发展，用户对云价值转化的思考也更加复杂有深度，而不是滞留于上云的表面。有更多的用户会考虑 PaaS、两地三中心容灾、混合云、多云间数据流转等应用场景。伴随着行业用户的多样性，OpenStack 也须要为不一样的业务负载（e.g. 人工智能、大数据、物联网）提供运行支撑，这些其实是用户业务深度融合与进一步提升平台自主性的刚性需求。用户须要的每每是一个总体的云解决方案，这里面不只仅只有 IaaS，但并不是全部的技术都会在 OpenStack 社区内获得发展。因此，社区在继 “可组合性” 的项目协做方式以后，在今年又提出了更加完全的 OpenInfra 思想，以更 “开放” 的态度拥抱一切能够组合的开源项目，将 OpenStack 打形成一个开源基础设施的集成引擎。

对于从 OpenStack 到 OpenInfra 的转变，我认为社区是作了长足准备的。从去年的轻量级安全容器项目 Kata Container（融合了虚拟化和容器技术）、今年的 CI/CD 项目 Zuul、再到融合了 IaaS 与 PaaS 的 Airship 与边缘计算项目 StarlingX，它们逐一成为 OpenStack 基金会的顶级项目与 OpenStack 项目并驾齐驱，搭建出整个 Open Infrastructure 的蓝图。

Mark Collier 还说过：“OpenStack 社区主要目的是为了解决问题，并不断完善计算、存储和网络。但如今已经不只限于这些。咱们正在创建技术堆栈，但这不是一个固定的堆栈，它是一个灵活的可编程基础设施技术栈。咱们须要将不一样的开源项目粘合在一块儿，而 OpenStack 社区成员已经得到了这方面的专业知识。”这段话凸显了 OpenStack 以社区运营为中心的管理特点，你要知道每一个社区都有本身的个性，协同社区间的合做双赢是一项极具工程与人文追求的事业，而 OpenStack 社区正为之付出努力，并在 OpenStack、OpenNFV、KVM、Ceph 社区之间获得了实践，这正是我所钦佩的。

其实我我的认为不管是 “可组合性” 仍是 OpenInfra，这些思路都是正确的。但在实践上却出现了误差。我以为可组合的粒度应该是 OpenStack 与其余开源项目，而非 OpenStack 下属项目（e.g. Keystone、Cinder、Neutron）与其余开源项目。OpenStack 内部的项目应该进一步加深紧密联系、互相依赖以提供更加完备而流畅的计算、存储、网络等基础设备资源的服务能力，再对外提供简易而统一的 API，以此实现开发式的 API 经济。从上文能够感觉到，在这一方面 Octavia 项目就是一个很棒的例子。惋惜的是，有些项目会但愿谋求独立运营，花费精力去适配诸如 Kubernets 之类的平台，最终致使方向分散，内部撕裂，成为 “四不像” 项目的结果。其实 OpenStack 的计算、存储和网络依旧存在改进的空间，例如：Nova Cell、Nova Placement、Cinder DR、Neutron DVR 等等。不知道是否有人计算过，花费了这么多人力与时间围绕着 OpenStack 体系构建起来的项目，再去对其余平台进行适配须要花费多少沟通、研发和讨论的成本？这是理想与现实之间的差距，也是我认为如今有些项目之因此变得疲软的缘由。

固然了，这也只是部分状况，如此庞大的开源社区，总会有各类各样的问题。如今的 OpenStack 依旧在迸发其旺盛的生命力，依旧快速增加的国内市场就是力证。不管如何，OpenStack 在这八年间不只成为了一个优秀的开源私有云架构，还极大推进 OpenFlow、Ceph 等开源项目的发展，甚至在全世界范围内传播开源、开发的思想与社区运营案例，仅凭这些 OpenStack 就是成功的。

曾经有人问我 OpenStack 之于我而言意味着什么？我说：开源。云的将来不会只有 OpenStack，也不会只有 Kubernetes，但却总会有主流的开源技术，例如：KVM、Container、Ceph、OVS 以及 Cassandra，万变不离其宗，做为一名云计算技术工程师，我看重的也是这些。