Jump to: navigation, search

Kilo更新日志

Revision as of 05:55, 3 May 2015 by Ray (talk | contribs) (Created page with "=== 升级提示 ===")
Other languages:
English • ‎日本語 • ‎한국어 • ‎русский • ‎中文（简体）‎ • ‎中文（台灣）‎

OpenStack 2015.1.0 (Kilo)更新日志

以此OpenStack Kilo版本的更新日志告慰Chris Yeoh在天之灵，虽然你已远离你的家人和我们，但你的心永远与我们同在。

Contents


OpenStack对象存储(Swift)

新功能

纠删码(beta)

Swift现在支持纠删码(EC)存储策略类型。这样部署人员、以极少的RAW容量达到极高的可用性，如同在副本存储中一样。然后，EC需要更多的CPU和网络资源，所以并不适合所有应用场景。EC非常适合在一个独立的区域内极少访问的、大容量数据。

Swift纠删码的实现对于用户是透明的。对于副本存储和纠删码存储的类型，在API上没有任何区别。

为了支持纠删码，Swift现在需要依赖PyECLib和liberasurecode。liberasurecode是一个可插件式的库，允许在你选择的库中实现EC算法。

更详细文档请参阅 http://swift.openstack.org/overview_erasure_code.html

复合型令牌(Composite tokens)

复合型令牌允许其他OpenStack服务以客户端名义将数据存储于Swift中，所以无论是客户端还是服务在更新数据时，都不需要双方彼此的授权。

一个典型的例子就是一个用户调用Nova存放一个VM的快照。Nova将指令传递给Glance，Glance将镜像写入Swift容器中的一组对象中。在这种场景下，用户在没有服务的合法的令牌情况下，无法直接修改快照数据。同样，服务自身也无法在没有用户合法令牌的情况下更新数据。但是数据的确存在于用户的Swift账户中，这样使得账户管理更简单。

更详细的文档请参阅http://swift.openstack.org/overview_backing_store.html

更小规模、不平衡集群的数据位置更新

Swift数据的存放位置现在根据硬件权重决定。当前，允许运维人员逐渐的添加新的区域(zones)和地域(regions)，而不需要立即触发大规模数据迁移。同时，如果一个集群是非平衡的(例如，在一个区域(zones)的集群中，其中一个的容量是另外一的两倍)，Swift会更有效的使用现有空间并且当副本在集群空间不足时发出警告。

全局性集群复制优化

区域(regions)之间复制时，每次复制只迁移一个副本。这样远程的区域(region)可以在内部复制，避免更多的数据在广域网(WAN)拷贝。

已知问题

  • 作为beta更新，纠删码(EC)的功能接近完成，但是对于某些功能仍然不完整(像多范围(multi-range)读取)，并且没有一个完整的性能测算。这个功能为了持久性依赖于ssync。部署人员督促我们做更大规模的测试，并且不要在生产环境部署中使用纠删码存储策略。

升级提示

像往常一样，你能在不影响最终用户体验的前提下，升级到这个版本的Swift。

  • 为了支持纠删码，Swift需要一个新的依赖PyECLib(和liberasurecode等)。并且eventlet的最低版本要求也升高了。


OpenStack 计算服务(Nova)

新功能

API v2.1

  • kilo版本中，我们仍然使用v2.0 API的代码提供v2.0 API的请求。我们希望v2.1将能够同时为v2.0和v2.1请求提供服务。
  • liberty v2.0现在被冻结了，所有功能被添加在v2.1 API中使用微版本(microversions)机制实现。kilo版本中微版本(microversion)更新包括：
    • 扩展keypair API支持x509证书，能够和Windows WinRM使用，这个功能是v2.1 API中第一个被以微版本(microversions)添加的功能。
    • 在os-extended-server-attributes暴露扩展属性
  • python-novaclient现在还不支持v2.1 API
  • Nova v2.1 API的策略执行得到优化。
    • 只在API入口执行策略
    • 对于单一的API，去掉了重复性规则
    • 所有的v2.1 API的策略规则使用'os_compute_api'作为前缀，以区别于v2 API。
    • 之前，由于在db层面权限检查的硬编码(hard-code)，部分Nova API并不支持策略的配置。总是需要admin用户权限。在Nova v2.1 API中硬编码(hard-code)权限检查被移除，使得API策略可配置。其余的硬编码(hard-code)将在Liberty版本被移除掉。

升级支持

  • https://review.openstack.org/#/c/97946/ 增加了编号为267的数据库迁移脚本，这个脚本主要扫描为空(null)的instances.uuid记录并且一旦发现就会导致失败，因为迁移中需要保证instances.uuid非空并且在那个字段加入了UniqueConstraint限制。为了避免数据库迁移失败，提供了一个帮助脚本用来搜索空(null)的instances.uuid的记录。运行'nova-manage db sync'之前，运行帮助脚本‘nova-manage db null_instance_uuid_scan’，默认情况下，该脚本只会检索记录，并将结果输出，不会改变任何内容。如果在参数中加入--delete，就会自动删除所有instances.uuid为空的记录。

调度器(Scheduler)

  • 一些列的性能优化
  • 我们在优化scheudler的代码结构，这将帮助我们能够演进和优化调度过程。这一点对于终端用户不可见。

Cells v2

  • 已经开始添加了对cell v2版本的支持，但是还没达到能够使用的程度。
  • 新的'nova-manage api_db sync' 和 'nova-manage api_db version'命令用于支持cell新的api数据库结构，但是还没有任何代码使用该数据库，所有没有必要建立。

计算资源驱动

Hyper-V

Libvirt (KVM)
VMware
Ironic

已知问题

  • Evacuate恢复部分代码存在损坏数据的潜在危险。在nova-compute启动过程中，虚拟化端会汇报instance的状态，用于检查物理机发生故障过程中，虚拟机是否被移走了(i.e. 被evacuated)。如果此时发现的确发生迁移了，那么本地的数据就会被彻底删除。这样就存在潜在的可能出现选择错误，虚拟机被错误的销毁。在libvirt节点上，这样的情况可能会由于改变系统的主机名引发。在vmware节点中，这个可能会由于尝试从两个不同的主机(不同的主机名)管理同一个vcenter引发。这个Bug可能会在Liberty中得到修复，但是在当前部署中，关闭这种行为的建议是设置destroy_after_evacuate=False。

注意：这个并不是回归(regression)并且在evacuate的设计中已经提到这个瑕疵。这个并不容易修复，所以使用这种方式绕过去(workaround)解决这个潜在的数据损坏。在liberty的修复记录：https://review.openstack.org/#/c/161444/。

  • 生成的配置文件样例可能会缺少某些oslo相关的配置

升级提示

Below are changes you should be aware of when upgrading. Where possible, The git commit hash is provided for you to find more information:

  • Neutron ports are no longer deleted after your server is deleted, if you created them outside of Nova: 1153a46738fc3ffff98a1df9d94b5a55fdd58777
  • EC2 API support has been deprecated, and is likely to be removed in kilo, see f098398a836e3671c49bb884b4a1a1988053f4b2
  • Websocket proxies need to be upgraded in a lockstep with the API nodes, as older API nodes will not be sending the access_url when authorizing console access, and newer proxy services (this commit and onward) would fail to authorize such requests 9621ccaf05900009d67cdadeb1aac27368114a61
  • After fully upgrading to kilo (i.e. all nodes are running kilo code), you should start a background migration of flavor information from its old home to its new home. Kilo conductor nodes will do this on the fly when necessary, but the rest of the idle data needs to be migrated in the the background. This is critical to complete before the Liberty release, where support for the old location will be dropped. Use "nova-manage migrate-flavor-data" to perform this transition.
  • Due to the improvement on Nova v2.1 API policy enforcement. There are a lot of change happened to v2.1 API policy. Because v2.1 API didn't released before, those change won't keep back-compatible. It is better to use policy sample configuration instead of old one.
  • VMware rescue VM behaviour no longer creates a new VM and instead happens in place: cd1765459a24e52e1b933c8e05517fed75ac9d41
  • force_config_drive = always has been deprecated, and force_config_drive = True should be used instead: c12a78b35dc910fa97df888960ef2b9a64557254
  • Running hyper-v, if you deployed code that was past this commit: b4d57ab65836460d0d9cb8889ec2e6c3986c0a9b but before this commit: c8e9f8e71de64273f10498c5ad959634bfe79975 you make have problems to manually resolve see: c8e9f8e71de64273f10498c5ad959634bfe79975
  • Changed the default value of: multi_instance_display_name_template see: 609b2df339785bff9e30a9d67d5c853562ae3344
  • Please use "nova-manage db null_instance_uuid_scan" to ensure the DB migrations will apply cleanly, see: c0ea53ce353684b48303fc59393930c3fa5ade58


OpenStack Image Service (Glance)

Key New Features

Known Issues

Upgrade Notes

  • Removed deprecated option db_enforce_mysql_charset. Corresponding commit: efeb69f9033a57a1c806f71ee3ed9fd3f4d2475e
  • Notifications for metadef resources are now supported. Corresponding commit: fd547e3717dc4a3a92c1cb2104c18608a4f4872a
  • VMware multiple datastores can be enabled by a few config changes. Corresponding commit: 96fb31d7459bd4e05e052053177dce4d38cdaf90
  • Removed the eventlet executor and added a new taskflow executor for async tasks. Corresponding commits: ae3135e1d67df77697a24fddaee3efeadb34a0dd and a39debfd55f6872e5f4f955b75728c936d1cee4b
  • Replace snet config with endpoint config. Corresponding commit: 41a9a065531ec946b4a9baf999f97d10fa493826
  • Digest algorithm is now configurable. Corresponding commit: 82194e0c422966422f7a4e2157125c7ad8fbc5b5
  • Cleanup chunks for deleted image that was in 'saving' state while deleting. Corresponding commit: 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea
  • Glance now uses graduated oslo.policy. Corresponding commit: cb7d5a4795bbdaf4dc3eaaf0a6fb1add52c09011
  • An image can now be deactivated. A new state called deactivated has been added to the Image data asset. Corresponding commit: b000c85b7fabbe944b4df3ab57ff73883328f40d


OpenStack Dashboard (Horizon)

Key New Features

  • Support for Federated authentication via Web Single-Sign-On -- When configured in keystone, the user will be able to choose the authentication mechanism to use from those support by the deployment. This feature must be enabled by changes to local_settings.py to be utilized. The related settings to enable and configure can be found here.
  • Support for Theming -- A simpler mechanism to specify a custom theme for Horizon has been included. Allowing for use of CSS values for Bootstrap and Horizon variables, as well as the inclusion of custom CSS. More details available here.
  • Sahara UX Improvements -- Dramatic improvements to the Sahara user experience have been made with the addition of guided cluster creation and guided job creation pages.
  • Launch Instance Wizard (beta) -- A full replacement for the launch instance workflow has been implemented in AngularJS to address usability issues in the existing launch instance workflow. Due to the late inclusion date and limited testing, this feature is marked as beta for Kilo and not enabled by default. To use the new workflow, the following change to local_settings.py is required: LAUNCH_INSTANCE_NG_ENABLED = True. Additionally, you can disable the default launch instance wizard with the following: LAUNCH_INSTANCE_LEGACY_ENABLED = False. This new work is a view into future development in Horizon.
  • Nova
    • allow service disable/enable on Hypervisor
    • Migrate all instances from host
    • expose serial console
  • Cinder
    • Cinder v2 by default
    • Managed/Unmanaged volume support -- allows admin to manage existing volumes not managed by cinder, as well as unmanage volumes.
    • Volume transfer support between projects
    • Volume encryption metadata support
  • Glance
    • View added to allow administrators to view/add/update Glance Metadata definitions
  • Heat
    • Stack Template view
    • Orchestration Resources Panel
    • Suspend/Resume actions for Stacks
    • Preview Stack view allows users to preview stacks specified in templates before creating them.
  • Trove
    • Resizing of Trove instances -- changing instance flavor
  • Ceilometer
    • Display IPMI meters values from Ceilometer
  • New Reusable AngularJS widgets in Horizon:
    • AngularJS table implementation
      • Table drawers -- expandable table content
      • improved client/server search
    • Transfer table widget
  • Configurable web root for Horizon beyond just '/'

Known Issues

Upgrade Notes

  • Django 1.7 is now supported.


OpenStack Identity (Keystone)

Key New Features

Hierarchical multitenancy

Projects can be nested under other projects by setting the parent_id attribute to an existing project when creating a new project. You can also discovery the parent-child hierarchy through the existing /v3/projects API.

Role assignments can now be assigned to both users and groups on subtrees in the project hierarchy.

This feature will require corresponding support across other OpenStack services (such as hierarchical quotas) in order to become broadly useful.

Fernet tokens

Unlike UUID tokens which must be persisted to a database, Fernet tokens are entirely non-persistent. Deployers can enable the Fernet token provider using [token] provider = keystone.token.providers.fernet.Provider in keystone.conf.

Fernet tokens require symmetric encryption keys which can be established using keystone-manage fernet_setup and periodically rotated using keystone-manage fernet_rotate. These keys must be shared by all Keystone nodes in a multi-node (or multi-region) deployment, such that tokens generated by one node can be immediately validated against another.

Identity federation

  • Keystone can now act as a federated identity provider (IdP) for another instance of Keystone by issuing SAML assertions for local users, which may be ECP-wrapped.
  • Added support for OpenID Connect as a federated identity authentication mechanism.
  • Added the ability to associate many "Remote IDs" to a single identity provider in Keystone. This will help in a case where many identity providers use a common mapping.
  • Added the ability for a user to authenticate via a web browser with an existing IdP, through a Single Sign-On page.
  • Federated tokens now use the token authentication method, although both mapped and saml2 remain available.
  • Federated users may now be mapped to existing local identities.
  • Groups specified in the mapping rulesets can be identified by name and domain.
  • Groups appearing in federated identity assertions may now be automatically mapped as locally existing groups with local user membership mappings (filtered by white and blacklists).

LDAP

  • Filter parameters specified by API users are now processed by LDAP itself, instead of by Keystone.
  • Experimental support was added to store domain-specific identity backend configuration in SQL using the HTTP API. The primary use case for this is to create a new domain with the HTTP API, and then immediately configure a domain-specific LDAP driver for it without restarting Keystone.

Authorization

  • The "assignment" backend has been split into a "resource" backend (containing domains, projects, and roles) and an "assignment" backend, containing the authorization mapping model.
  • Added support for trust redelegation. If allowed when the trust is initially created, a trustee can redelegate the roles from the trust via another trust.
  • Added support for explicitly requesting an unscoped token from Keystone, even if the user has a default_project_id attribute set.
  • Deployers may now opt into disallowing the re-scoping of scoped tokens by setting [token] allow_rescope_scoped_token = false in keystone.conf.


Upgrade Notes

  • XML support in Keystone has been removed as of Kilo. When upgrading from Juno to Kilo, it is recommended that references to XML and XmlBodyMiddleware be removed from the Keystone Paste configuration. This includes removing the XML middleware filters and the references from the public_api, admin_api, api_v3, public_version_api, admin_version_api and any other pipelines that may contain the XML filters.
  • All previous extensions (OS-FEDERATION, OS-OAUTH1, OS-ENDPOINT-POLICY and OS-EP-FILTER) are now enabled by default, and are correspondingly marked as either "experimental" or "stable".
  • SQL Schema Downgrades are no longer supported. This change is the result of evaluation that downward SQL migrations are not well tested and become increasingly difficult to support with the volume of data-change that occurs in many of the migrations.
  • The following python libraries are now required: cryptography, msgpack-python, pysaml2 and oauthlib.
  • keystone.middleware.RequestBodySizeLimiter is now deprecated in favor of oslo_middleware.sizelimit.RequestBodySizeLimiter and will be removed in Liberty.
  • Eventlet-specific configuration options such as public_bind_host, bind_host, admin_bind_host, admin_port, public_port, public_workers, admin_workers, tcp_keepalive, tcp_keepidle have been moved from the [DEFAULT] configuration section to a new configuration section called [eventlet_server]. Similarly, Eventlet-specific SSL configuration options such as enable, certfile, keyfile, ca_certs, cert_required have been moved from the [ssl] configuration section to a new configuration section called [eventlet_server_ssl].
  • keystone.token.backends.sql has been removed in favor of keystone.token.persistence.backends.sql.
  • keystone.token.backends.kvs has been removed in favor of keystone.token.persistence.backends.kvs.
  • keystone.token.backends.memcache has been removed in favor of keystone.token.persistence.backends.memcache.
  • keystone.assignment.backends.kvs has been removed in favor of keystone.assignment.backends.sql.
  • keystone.identity.backends.kvs has been removed in favor of keystone.identity.backends.sql.
  • keystone.contrib.stats.core.StatsMiddleware has been removed in favor of external tooling.
  • keystone.catalog.backends.templated.TemplatedCatalog has been removed in favor of keystone.catalog.backends.templated.Catalog.
  • keystone.contrib.access.core.AccessLogMiddleware has been removed in favor of external access logging.
  • keystone.trust.backends.kvs has been removed in favor of keystone.trust.backends.sql.
  • [catalog] endpoint_substitution_whitelist has been removed from keystone.conf as part of a related security hardening effort.
  • [signing] token_format has been removed from keystone.conf in favor of [token] provider.

OpenStack Network Service (Neutron)

Key New Features

  • DVR now supports VLANs in addition to VXLAN/GRE
  • ML2 Hierarchical Port Binding
  • New LBaaS Version 2 API
  • Portsecurity support for the OVS ML2 Driver
  • New Plugins supported in Kilo include the following:
    • A10 Networks LBaaS V2 Driver
    • Brocade LBaaS V2 Driver
    • Brocade ML2 driver for MLX and ICX switches
    • Brocade L3 routing plugin for MLX switch
    • Brocade Vyatta vRouter L3 Plugin
    • Brocade Vyatta vRouter Firewall Driver
    • Brocade Vyatta vRouter VPN Driver
    • Cisco CSR VPNaaS Driver
    • Dragonflow SDN based Distributed Virtual Router L3 Plugin
    • Freescale FWaaS Driver
    • Intel Mcafee NGFW FWaaS Driver
    • IPSEC Strongswan VPNaaS Driver

Known Issues

  • The Firewall-as-a-Service project is still marked as experimental for the Kilo release.
  • Bug 1438819
    • When a new subnet is created on an external network, all existing routers with gateways on the network will get a new address allocated from it. For IPv4 networks, this could consume the entire subnet for router gateway ports.

Upgrade Notes

From Havana, Neutron no longer supported an explicit lease database (https://bugs.launchpad.net/bugs/1202392). This left dead code including unused environment variable. In order to remove the dead code (https://review.openstack.org/#/c/152398/), a change to the dhcp.filter is required, so that line:

dnsmasq: EnvFilter, dnsmasq, root, NEUTRON_NETWORK_ID=

Be replaced by:

dnsmasq: CommandFilter, dnsmasq, root

After advanced services were split into separate packages and received their own service configuration files (specifically, etc/neutron/neutron_lbaas.conf, etc/neutron/neutron_fwaas.conf and etc/neutron/neutron_vpnaas.conf), active service provider configuration can be different after upgrade (specifically, default load balancer (haproxy) and vpn (openswan) providers can be enabled for you even though you previously disabled them in neutron.conf). Please make sure you review configuration after upgrade so that it reflects the desired state of service providers.

Note: this will have no effect if the related service plugin is not loaded in neutron.conf.


Other Notes (Deprecation/EOL etc)

  • Deprecation
    • Brocade Monolithic plugin for Brocade's VDX/VCS series of hardware switches will be deprecated in the L-Release. The functionality provided by this plugin is now addressed by the ML2 Driver available for the VDX series of hardware. The plugin is slated for removal after this release cycle.
    • The monolithic Cisco Meta plugin for Nexus1000V will be deprecated in the L-Release. The functionality provided by this plugin is now available with the Cisco Nexus1000V ML2 mechanism driver. The monolithic plugin is slated for removal after this release cycle.

OpenStack Block Storage (Cinder)

Key New Features

  • From this point forward any new database schema upgrades will not require restarting Cinder services right away. The services are now independent of schema upgrades. This is part one to Cinder supporting rolling upgrades!
  • Ability to add/remove volumes from an existing consistency group. Read docs for more info.
  • Ability to create a consistency group from an existing consistency group snapshot. Read docs for more info.
  • Create more fine tuned filters/weighers to set how the scheduler will choose a volume backend. Read the docs for more info.
  • Encrypted volumes can now be backed up using the Cinder backup service. Read the docs for more info.
  • Ability to create private volume types. This is perfect when you want to make volume types available to only a specific tenant or to test it before making available to your cloud. To do so use the cinder type-create <name> --is-public.
  • Oversubscription with thin provision is configurable. Read docs for more info.
  • Ability to add descriptions to volume types. To do so use cinder type-create <name> <description>
  • Cinder now can return multiple iSCSI paths information so that the connector can attach volumes even when the primary path is down (when connector's multipath feature is enabled or not enabled).

Upgrade Notes

  • The 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis. If you use this option, please ensure your configuration files are updated.


OpenStack Telemetry (Ceilometer)

Key New Features

  • Support to add jitter to polling cycles to ensure pollsters are not querying service's api at the same time
  • Ceilometer API RBAC support
  • Improved Event support:
    • Multi-pipeline support to enable unique processing and publishing of events
    • Enabled ability to capture raw notification messages for auditing and postmortem analysis
    • Support for persisting events into ElasticSearch
    • Publishing support to database, http, file, kafka and oslo.messaging supported message queues
    • Option to split off the events persistence into a separate database
    • Telemetry now supports to collect and store all the event type meters as events. A new option, disable_non_metric_meters, was added to the configuration in order to provide the possibility to turn off storing these events as samples. For further information please see the Telemetry Configuration Reference
    • The Administrator Guide in OpenStack Manuals was updated with a new Events section, where you can find further information about this functionality.
  • Improved pipeline publishing support:
    • Support to publish events and samples to Kafka or HTTP targets
    • Publish data to multiple queues
  • Additional meters
    • memory and disk meters for Hyper-V
    • disk meters for LibVirt
    • power and thermal related IPMI meters, more meters from NodeManager
    • ability to meter Ceph
  • IPv6 support enabled in Ceilometer udp publisher and collector
  • Gnocchi dispatch support for ceilometer-collector
  • Self-disabled pollster mechanism


Upgrade Notes

  • Deprecated meters:
    • The instance:<flavor> meter is deprecated in the Kilo release. In order to retrieve samples or statistics based on flavor you can use the following queries:
  statistics:
  ceilometer statistics -m instance -g resource_metadata.instance_type

  samples:
  ceilometer sample-list -m instance -q metadata.instance_type=<value>


OpenStack Orchestration (Heat)

Key New Features

Upgrade Notes

  • The default of the configuration option "num_engine_workers" has changed from 1 to a number based on the the number of CPUs. This is now the same as the way other projects set the number of workers.
  • The default for the configuration option "max_nested_stack_depth" has been increased to 5.
  • There is a new configuration option "convergence" it is by default off. This feature is not yet complete and this option should remain off.
  • In preparation of an upcoming major feature (convergence) there have been some significant DB schema changes. It is suggested that the heat-engine is shutdown during schema upgrades.

Other Notes (Deprecation/EOL etc)

Deprecation

  • The follow resources are deprecated OS::Heat::HARestarter and OS::Heat::CWLiteAlarm
  • The CloudWatch API (heat-api-cw)


OpenStack Database service (Trove)

Key New Features

  • Support for a new replication strategy based on async GTID replication (new in MySQL 5.6)
    • We now support for creating n-replicas from a single master in one API call
    • We also support for failover from an unresponsive master to the most up-to-date slave can now be achieved using the new 'eject-master' API
  • Support for Trove guest managers to support the following new datastores:
    • Vertica, and Vertica Cluster
    • DB2
    • CouchDB
  • Extended current management API layer :
    • We now have a new management API to support listing and viewing deleted trove instances
    • We also added a new management API to ping a datastore guestagent via the RPC mechanism
  • Horizon updates to support resize of Trove instances.
  • Users now have the ability to edit/update the names of Trove instances
  • Integration with the cross-project OpenStack profiling library (OSProfiler)

Upgrade Notes

  • We migrated from deprecated oslo-incubator messaging code to the official oslo.messaging python module. Please look at git.openstack.org/cgit/openstack/trove/tree/etc/trove/trove.conf.sample#n18 for more details on the changed config values that were added to support this, (Change)
  • Datastores and strategies that are not currently being tested by any CI have been moved into an 'experimental' section in their respective modules. Once these datastores and strategies have appropriate tests exercising and gating against them in CI, they will be graduated to 'stable'.
  • Added new documentation to help with the process of building trove guest images for different datastores at http://docs.openstack.org/developer/trove/dev/building_guest_images.html


OpenStack Data Processing service (Sahara)

Key New Features

  • New plugins, their features and versions:
    • MAPR
    • Apache Storm
    • Apache Hadoop 2.6.0 was added, Apache Hadoop 2.4.1 deprecated
    • New services for CDH plugin added up to HDFS, YARN, Spark, Oozie, HBase, ZooKeeper and other services
  • Added indirect VM access for better utilization of floating IPs
  • Added event log support to have detailed info about provisioning progress
  • Optional default node group and cluster templates per plugin
  • Horizon updates:
    • Guided cluster creation and job execution
    • Filtering on search for objects
  • Editing of Node Group templates and Cluster templates implemented
  • Added Shell Job Type for clusters running Oozie
  • New Job Types endpoint to query list of the supported Job Types


Upgrade Notes

Details: http://docs.openstack.org/developer/sahara/userdoc/upgrade.guide.html#juno-kilo

  • Sahara now requires policy.json configuration file.


OpenStack Bare Metal service (Ironic)

Key New Features

State Machine

Ironic now uses a formal model for the logical state of each node it manages.[1] This has enabled the addition of two new processes: cleaning and inspection.

  • Automatic disk erasure between tenants is now enabled by default. This may be extended to perform additional cleaning steps, such as re-applying firmware, resetting BIOS settings, etc.[2]
  • Both in-band and out-of-band methods are available to inspect hardware. These methods may be used to update Node properties automatically.[3]

Version Headers

The Ironic REST API expects a new X-OpenStack-Ironic-API-Version header be passed with each HTTP[S] request. This header allows client and server to negotiate a mutually supported interface.[4] In the absence of this header, the REST service will default to a compatibility mode and yield responses compatible with Juno clients. This mode, however, prevents access to most features introduced in Kilo.

Hardware Driver Changes

The following new drivers were added:


The following enhancements were made to existing drivers:


Support for third-party and out-of-tree drivers is enhanced by the following two changes:

  • Drivers may store their own "internal" information about Nodes.
  • Drivers may register their own periodic tasks to be run by the Conductor.
  • vendor_passthru methods now support additional HTTP methods (eg, PUT and POST).
  • vendor_passthru methods are now discoverable in the REST API. See node vendor passthru and driver vendor passthru

Other Changes

  • Logical names may be used to address Nodes, in addition to their canonical UUID.
  • For servers with varied local disks, hints may be supplied that affect which disk device the OS is provisioned to.
  • Support for fetching kernel, ramdisk, and instance images from HTTP[S] sources directly has been added to remove the dependency on Glance. Using ironic as a standalone service
  • Nodes may be placed into maintenance mode via REST API calls. An optional maintenance reason may be specified when doing so.

Known Issues

  • Running more than one nova-compute process is not officially supported.
    • While Ironic does include a ClusteredComputeManager, which allows running more than one nova-compute process with Ironic, it should be considered experimental and has many known problems.
  • Drivers using the "agent" deploy mechanism do not support "rebuild --preserve-ephemeral"

Upgrade Notes

  • IPMI Passwords are now obfuscated in REST API responses. This may be disabled by changing API policy settings.
  • The "agent" class of drivers now support both whole-disk and partition based images.
  • The driver_info parameters of "pxe_deploy_kernel" and "pxe_deploy_ramdisk" are deprecated in favour of "deploy_kernel" and "deploy_ramdisk".
  • Drivers implementing their own version of the vendor_passthru() method has been deprecated in favour of the new @passthru decorator.

Juno to Kilo

The recommended upgrade process is documented here:

Upgrading from Icehouse "nova-baremetal"

An upgrade from an Icehouse Nova installation using the "baremetal" driver directly to Kilo Ironic is untested and unsupported. Instead, please follow the following upgrade path:

  1. Icehouse Nova "baremetal" -> Juno Nova "baremetal"
  2. Juno Nova "baremetal" -> Juno Ironic
  3. Juno Ironic -> Kilo Ironic

Documentation for steps 1 and 2 is available at: https://wiki.openstack.org/wiki/Ironic/NovaBaremetalIronicMigration


OpenStack文档

  • ↑ [1]New Ironic State Machine
  • ↑ [2]Node Cleaning
  • ↑ [3]Hardware Inspection
  • ↑ [4]REST API "micro" versions
    • Retrieved from "https://wiki.openstack.org/w/index.php?title=ReleaseNotes/Kilo/zh-hans&oldid=79572"