* FLAVOR_EXTRA_KEYS setting deprecated. The use of this key has been replaced with direct calls to the nova and [http://docs.openstack.org/developer/glance/metadefs-concepts.html glance api] as appropriate.

* FLAVOR_EXTRA_KEYS setting deprecated. The use of this key has been replaced with direct calls to the nova and [http://docs.openstack.org/developer/glance/metadefs-concepts.html glance api] as appropriate.

* FLAVOR_EXTRA_KEYS setting deprecated. The use of this key has been replaced with direct calls to the nova and [http://docs.openstack.org/developer/glance/metadefs-concepts.html glance api] as appropriate.

General Upgrade Notes

The simplejson package is an optional requirement in most projects, therefore it's not listed in all project's requirements.txt file. However, if you're using it, e.g. better performance with python 2.6 on RHEL 6, then you will need simplejson >= 2.2.0. See https://bugs.launchpad.net/oslo-incubator/+bug/1361230 for details.

Important new features are highlighted below. Please read the CHANGELOG and associated documentation.

Storage policies

Keystone v3 support

Server-side account-to-account copy

Better partition placement when adding a new server, zone, or region.

Zero-copy GET responses using splice()

Parallel object auditor

Known Issues

None at this time

Upgrade Notes

As always, you can upgrade your Swift cluster with no downtime for end-users. Please refer to sample config files and documentation before every release.

There have been some logging changes that need to be called out. In all cases, well-behaved log processors will not be affected.

Storage node (account, container, object) logs now have the PID logged at the end of the log line.

Object daemons now send a user-agent string with their full name (e.g. "obj" is now "object").

Once an additional storage policy has been enabled, downgrading to Swift pre-2.0.0 will cause any additional storage policies to become unavailable.

As part of an effort to eventually update the default port to swift to an non-IANA-assigned range, bind_port is now a required setting. Anyone currently explicitly setting the ports will not be affected. However, if you do not currently set the ports, please ensure that your *_server.conf has bind_port set to match your ring as part of your upgrade.

Note that storage policies include a new daemon, the container-reconciler.

TempURL default allowed methods config setting now also allows POST and DELETE. This means tempurls can be created for these verbs. It does not affect any existing tempurls.

Scheduling

Extensible Resource Tracking. The set of resources tracked by nova is hard coded, this change makes that extensible, which will allow plug-ins to track new types of resources for scheduling. launchpadspecification

Allow a host to be evacuated, but with the scheduler selecting destination hosts for the instances moved. launchpadspecification

vmware

Refactor the vmware driver's spawn functionality to be more maintainable. This work was internal, but is mentioned here because it significantly improves the supportability of the VMWare driver. launchpadspecification

Nova is now supporting the Cinder V2 API. The Cinder V1 API is deprecated in Juno and Nova will switch over to Cinder V2 by default in the "L" release.

Debug log output in python-novaclient has changed slightly to improve readability. The sha1 hash of the keystone token is now printed instead of the token itself - greatly shortening the amount of content being printed while still retaining the ability to determine token mismatch scenarios. In addition, some extra '\n' characters that were being added are removed. Double-check any log parsers!

libvirt.volume_drivers config param for nova.conf is deprecated, to be removed in the Lxxxx release. In general, this should affect only a small number of developers working on drivers. If this is you, the recommended approach is to continue your work inside a nova tree.

The ability to upload a public image is now admin-only by default. To continue to use the previous behaviour, edit the publicize_image flag in etc/policy.json to remove the role restriction.

The requirement and check on UTF-8 charset for DB tables is enforced, operator need to migration tables and existing data to UTF-8 manually if glance-manage complains it during the sync.

glance workers will now be equal to the number of CPUs available by default if not explicitly specified in glance-api.conf and/or glance-registry.conf

There is no upgrade impact to glance-api workers since glance-api.conf previously hard-coded the workers value to 1 so anyone upgrading to tihs will still get whatever value was set in glance-api.conf prior to this change. There is an upgrade impact to the glance-registry workers since glance-registry.conf did not hard-code the workers value to 1 before this change. So anyone upgrading to this change that does not have workers specified in glance-registry.conf will now be running multiple workers by default when they restart the glance registry service.

OpenStack Dashboard (Horizon)

Key New Features

Sahara

The OpenStack Data Processing project (Sahara) was formally included into the integrated release in Juno and Horizon includes broad support for managing your data processing. You can specify and build clusters to utilize several data types with user specified jobs while tracking the progress of those jobs.

Neutron Features

Neutron added several new features in Juno, including:

DVR (Distributed Virtual Routing)

L3 HA support

IPv6 subnet modes

Horizon provides support for these new features with the Juno release. These features provide much greater flexibility in specifying software defined networks.

An existing feature in Neutron that Horizon now supports is the MAC learning extension.

Glance Features

In Juno, Glance introduced the ability to manage a catalog of metadata definitions where users can register the metadata definitions to be used on various resource types including images, volumes, aggregates, and flavors. Support for viewing and editing the assignment of these metadata tags is included in Horizon.

In Juno, Glance introduced the ability to manage a catalog of metadata definitions where users can register the metadata definitions to be used on various resource types including images, aggregates, and flavors. Support for viewing and editing the assignment of these metadata tags is included in Horizon.

Cinder Features

In a continued effort to provide fuller API support, several features supported by Cinder are now supported in Horizon in the Juno release. Users can now utilize swift to store volume backups from Horizon as well as restore volumes from these backups.

In a continued effort to provide fuller API support, several features supported by Cinder are now supported in Horizon in the Juno release. Users can now utilize swift to store volume backups from Horizon as well as restore volumes from these backups.

Other features of the Cinder API not previously supported by Horizon added in Juno include:

Enabling resetting the state of a snapshot

Enabling resetting the state of a volume

Supporting upload-to-image

Volume retype

QoS (quality of service) support

Trove

Trove supports potentially using numerous different datastores, e.g., mysql, redis, mongodb. Users can now select from the list of datastores supported by the cloud operator when creating their database instances.

Trove supports potentially using numerous different datastores, e.g., mysql, redis, mongodb. Users can now select from the list of datastores supported by the cloud operator when creating their database instances.

Another addition is support for utilizing and restoring from incremental database backups.

To improve support for Neutron based clouds, when creating a database instance, the user can now specify the NIC for the database instance on creation allowing direct access to the instance by the user.

Nova

The new nova instance actions panel provides a list of all actions taken on all instances in the current project allowing users to view resulting errors or actions taken by other users on those instances.

Administrators now have the ability to evacuate instances off hypervisors which can aid in system maintenance by providing a mechanism to migrate all instances to other hosts.

Improved Plugin Support

The plugin system in Horizon continued to improve in the Juno release.
Some of those improvements:

Support for adding plugin specific AngularJS modules

Support for adding static files, e.g., CSS, JS, images

Ability to add exceptions

Fixing ordering issues

Numerous other bug fixes

Enhanced RBAC support

In an ongoing effort to support richer role based access control (RBAC) in Horizon, the views for several more services were enhanced with RBAC checks to determine user access to actions. The newly supported services are compute, network and orchestration. These changes allow operators to implement finer grained access control than just "member" and "admin".

The identity panels (domains, projects, users, roles, groups) have also been converted to support RBAC at the view level. The identity panels have been moved from the admin dashboard into their own 'Identity' dashboard and accessibility is determined by policies alone. This is the first step toward consolidating the near duplicate content of the project and admin dashboards into single views supporting a wide range of roles.

UX Changes

In Juno, Horizon transitioned to utilizing Bootstrap v3. Horizon had been pinned to an older version of Bootstrap for several releases. This change now allows Horizon to pick up numerous bug fixes and overall improvements in the Bootstrap framework. The look and feel remains mainly consistent with the Havana release.

JavaScript Libraries Extracted

As part of the Horizon team's ongoing efforts to split the repository into more logical pieces, all the 3rd party JavaScript libraries that Horizon depends on have been removed from the Horizon code base and python xstatic packages have been utilized instead. The xstatic format allows for easy consumption by the Django framework Horizon is built on. Now JavaScript libraries are utilized like any other python dependency in Horizon.

As part of the Horizon team's ongoing efforts to split the repository into more logical pieces, all the 3rd party JavaScript libraries that Horizon depends on have been removed from the Horizon code base and python xstatic packages have been utilized instead. The xstatic format allows for easy consumption by the Django framework Horizon is built on. Now JavaScript libraries are utilized like any other python dependency in Horizon.

Conversion from LESS to SCSS

The supported stylesheets in Horizon have been converted to utilize SCSS rather than LESS. The change was necessary due to a prevalent lack of support for LESS compilers in python. This change also allowed us to upgrade to Bootstrap 3, as parts of the Bootstrap 3 LESS stylesheets were not supported by existing python based LESS compilers.

The supported stylesheets in Horizon have been converted to utilize SCSS rather than LESS. The change was necessary due to a prevalent lack of support for LESS compilers in python. This change also allowed us to upgrade to Bootstrap 3, as parts of the Bootstrap 3 LESS stylesheets were not supported by existing python based LESS compilers.

Known Issues

Rendering issues in extensions

The conversion to utilizing Bootstrap v3 can cause content extensions written on top of Horizon to have rendering issues. Most of these are fixed by a simple CSS class name substitutions. These issues are primarily seen with buttons and panel content widths.

Online Compression

With the move to SCSS, there may be issues with utilizing online compression in non-DEBUG mode in Horizon. Offline compression continues to work as in previous releases.

The templated catalog backend now supports generating service catalogs for Identity API v3.

Service names were added to the v3 service catalog.

Services can now be filtered by name ( GET /v3/services?name={service_name}).

Known Issues

LDAP paged search results don't work with python-ldap 2.4

When using an LDAP backend with paged search results enabled, AttributeErrors will be encountered if python-ldap 2.4 is being used. This is due to a backwards incompatible API change in python-ldap. The issue can be worked around in a few ways:

Disabling paging of search results by setting page_size to 0 in the [ldap] section of keystone.conf.

Downgrade python-ldap to version 2.3.x.

LDAP paged search results don't work with python-ldap 2.4

When using an LDAP backend with paged search results enabled, AttributeErrors will be encountered if python-ldap 2.4 is being used. This is due to a backwards incompatible API change in python-ldap. The issue can be worked around in a few ways:

Disabling paging of search results by setting page_size to 0 in the [ldap] section of keystone.conf.

LDAP configuration options that previously contained the deprecated tenant terminology have been superseded by options using the term project.

Proxy methods from the identity backend to the assignment backend (created to provide backwards compatibility as a result of the split of the Assignment backend from the Identity backend), have been removed. This should only affect custom, out-of-tree API extensions.

Loading authentication plugins solely by class name in keystone.conf is now deprecated in favor of loading them by custom-method-name = custom_package.CustomClass pairs, and then defining the sequence of authentication methods as a list (methods = custom-method-name, password).

In-tree token drivers (keystone.token.backends) have been moved to keystone.token.persistence.backends. Proxy objects exist to maintain compatibility. If a non-default value is used, it is recommended the value of the driver option in the [token] section of keystone.conf is updated to use the new location.

All KVS backends besides the token driver have been formally deprecated.

LDAP/AD configuration: All configuration options containing the term "tenant" have been deprecated in favor of similarly named configuration options using the term "project" (for example, tenant_id_attribute has been replaced by project_id_attribute).

OpenStack Network Service (Neutron)

Key New Features

DB migration refactor and new timeline

Distributed Virtual Router Support (DVR)

Full IPV6 support for tenant networks

High Availability for the L3 Agent

ipset support for security groups in place of iptables (this option is configurable)

Known Issues

This is the first release for DVR and HA L3. The Neutron team desires to designate these features as production ready in Kilo and requests that deployers test on non-critical workloads and report any issues.

FWaaS is still labeled as experimental, as it does not allow you to have more than one FW per tenant.

Upgrade Notes

DB migration from the previous releases (icehouse or havana)

In Icehouse or Hanava releases, the db migration operation is optional. If your Neutron database is not stamped (i.e., there is the db migration version info), please make sure to "stamp icehouse" before running the upgrade db migration to Juno.

Implemented distributed mode for Sahara: sahara-all process is decoupled into sahara-api and sahara-engine. You can run several instances of sahara-api and sahara-engine on different hosts. Note that the feature implementation is considered to be in alpha-state.

Also sqlite database is not supported anymore. Please use MySQL or PostgreSQL
db backends for Sahara. Sqlite support was dropped because it doesn't support
(and not going to support, see http://www.sqlite.org/omitted.html) ALTER
COLUMN and DROP COLUMN commands required for DB migrations between versions.

You can find more info about config file options in Sahara repository in file
"etc/sahara/sahara.conf.sample".

Sahara Dashboard was merged into OpenStack Dashboard

The Sahara Dashboard is not available in Juno release. Instead it's
functionality is provided by OpenStack Dashboard out of the box.
The Sahara UI is available in OpenStack Dashboard in
"Project" -> "Data Processing" tab.

Note that you have to properly register Sahara in Keystone in
order for Sahara UI in the Dashboard to work.

VM user name changed for HEAT infrastructure engine

We've updated HEAT infrastructure engine ("infrastructure_engine=heat") to
use the same rules for instance user name as in direct engine. Before the
change user name for VMs created by Sahara using HEAT engine was always
'ec2-user'. Now user name is taken from the image registry as it is described
in the documentation.

Note, this change breaks Sahara backward compatibility for clusters created
using HEAT infrastructure engine before the change. Clusters will continue to
operate, but it is not recommended to perform scale operation over them.

Anti affinity implementation changed

Starting with Juno release anti affinity feature is implemented using server
groups. There should not be much difference in Sahara behavior from user
perspective, but there are internal changes:

Server group object will be created if anti affinity feature is enabled.

New implementation doesn't allow several affected instances on the same host even if they don't have common processes. So, if anti affinity enabled for 'datanode' and 'tasktracker' processes, previous implementation allowed to have instance with 'datanode' process and other instance with 'tasktracker' process on one host. New implementation guarantees that instances will be on different hosts.

Note, new implementation will be applied for new clusters only. Old implementation will be applied if user scales cluster created in Icehouse.

OpenStack Documentation

This release, the OpenStack Foundation funded a five-day book sprint to write the new OpenStack Architecture Design Guide. It offers architectures for general purpose, compute-focused, storage-focused, network-focused, multi-site, hybrid, massively scalable, and specialized clouds.

The Install Guides have had a lot of clean up and standardization: uses common message queue (RabbitMQ), replaces openstack-config (crudini) commands with config file editing for improved learning opportunities and consistency, references a generic SQL database so that MariaDB or MySQL can be substituted, and replaces auth_port and auth_protocol with identity_uri, and auth_host with auth_uri throughout. The Install Guides are thoroughly tested on each distribution and continuously published until the official release packages are available to everyone.

The User Guide now contains Database Service for OpenStack information.

The Command-Line Reference has been updated with new client releases and now contains additional chapters for the common OpenStack client, the trove-manage client, and the Data processing client (sahara).