Dec 032012
 

11月22号,已经发布的G1版本,有老外专门写了一个总结,不过需要大家应该是无法直接访问。我就简单翻译一下。

修补了399个bug,其中nova是185个bug,比较恐怖的bug数量。刚刚Folsom的第一个补丁也发布了,nova修补了81个bug,这里面应该是很多是重叠的。

里面关于nova,keystone等组件的变化,都是值得关注的。

  • keystone增加的RABC,简单点说,就是基于角色的权限管理,增加这个功能,用起来才能比较方便。
  • nova的变化其实很大,nova compte不直接访问数据库,减少数据库的压力。另外支持RAW和LVM的快照,这也是一个重大突破啊,未来应该会支持增量备份。
  • glance感觉变化不是很大。目前应该对swift支持已经不错。就看未来对cinder的支持。
  • Quantum是重头戏,G1的版本还是没有实现nova network的全部功能,mutilhost还是不支持,等待G2.
  • Horizon的开发是最痛苦的,所有的组件的变化,都会反馈到他上面。olso,就是以前的Openstack common改名,估计又要做不少调整。
  • G1版本增加的功能不算太多,应该大量的精力会集中在修补bug上。G2的功能会增加更多。

What to expect from Grizzly-1 milestone

The first milestone of the OpenStack Grizzly development cycle is just out. What should you expect from it ? What significant new features were added ?

The first milestones in our 6-month development cycles are traditionally not very featureful. That’s because we are just out of the previous release, and still working heavily on bugs (this milestone packs 399 bugfixes !). It’s been only one month since we had our Design Summit, so by the time we formalize its outcome into blueprints and roadmaps, we are just getting started with feature implementation. Nevertheless, it collects a lot of new features and bugfixes that landed in our master branches since mid-September, when we froze features in preparation for the Folsom release.

Keystone is arguably where the most significant changes landed, with a tech preview of the new API version (v3), with policy and RBAC access enabled. A new ActiveDirectory/LDAP identity backend was also introduced, while the auth_token middleware is now shippedwith the Python Keystone client.

In addition to fixing 185 bugs, the Nova crew removed nova-volume code entirely (code was kept in Folsom for compatibility reasons, but was marked deprecated). Virtualization drivers no longer directly access the database, as a first step towards completely isolating compute nodes from the database. Snapshots are now supported on raw and LVM disks, in addition to qcow2. On the hypervisors side, the Hyper-V driver grew ConfigDrive v2 support, while the XenServer one can now use BitTorrent as an image delivery mechanism.

The Glance client is no longer copied within Glance server (you can still find it with the Python client library), and the Glance SimpleDB driver reaches feature parity with the SQLAlchemy based one. A number of cleanups were implemented in Cinder, including in volume drivers code layout and API versioning handling.  Support for XenAPI storage manager for NFS is back, while the API grew a call to list bootable volumes and a hosts extensionto allow service status querying.

The Quantum crew was also quite busy. The Ryu plugin was updated and now features tunnel support. The preparatory work to add advanced services was landed, as well as support for highly-available RabbitMQ queues. Feature parity gap with nova-network was reduced by the introduction of a Security Groups API.

Horizon saw a lot of changes under the hood, including unified configuration. It now supports Nova flavor extra specs. As a first step towards providing cloud admins with more targeted information, a system info panel was added. Oslo (formerly known as openstack-common) also saw a number of improvements. The config module (cfg) was ported to argparse. Common service management code was pushed to the Oslo incubator, as well as a generic policy engine.

That’s only a fraction of what will appear in the final release of Grizzly, scheduled for April 2013. A lot of work was started in the last weeks but will only land in the next milestone. To get a glimpse of what’s coming up, you can follow the Grizzly release status page !

  4 Responses to “Openstack Grizzly 1版本变化”

  1. openstack到什么版本才考虑instance的存储啊?为什么主存储到现在还没动静,cinder和swift已经风声水起了呢???

  2. 创建flavor的时候会有这样一个参数 RXTX_Factor ,给出的文档是这样解释的:
    Optional property allows created servers to have a different bandwidth cap than that defined in the network they are attached to. This factor is multiplied by the rxtx_base property of the network. Default value is 1.0 (that is, the same as attached network).
    疑问:虚拟机宽带上限是否依赖“宿主主机”的宽带能力。
    猜测:openstack有一个带宽基准,虚拟机的带宽在这个基准上乘以 参数RXTX_Factor的值, 进而决定虚拟机带宽上限。
    (ps:宿主主机,computer节点,启动虚拟机的地方)

  3. 十分感谢您百忙之中的回答,还是有些困惑。看了一个相对靠谱的网页(http://lists.openstack.org/pipermail/openstack-dev/2013-February/005302.html),您对这个参数是怎样理解的呢?

 Leave a Reply

(required)

(required)