Main binary renamed to sahara-all¶

The All-In-One sahara binary has been renamed fromsahara-apitosahara-all. The new name should be used in all cases where theAll-In-One sahara is desired.

Authentication middleware changes¶

The custom auth_token middleware has been deprecated in favor of the keystonemiddleware. This change requires an update to the sahara configuration file. Toupdate your configuration file you should replace the following parameters fromthe[DEFAULT] section with the new parameters in the[keystone_authtoken] section:

Additionally, the parametersos_auth_protocol,os_auth_host,andos_auth_port have been combined to create theauth_uriandidentity_uri parameters. These new parameters should befull URIs to the keystone public and admin endpoints, respectively.

For more information about these configuration parameters please seetheSahara Configuration Guide.

Database package changes¶

The oslo based code from sahara.openstack.common.db has been replaced bythe usage of the oslo.db package. This change does not require anyupdate to sahara’s configuration file.

Additionally, the usage of SQLite databases has been deprecated. Please useMySQL or PostgreSQL databases for sahara. SQLite has been deprecated because itdoes not, and is not going to, support theALTERCOLUMN andDROPCOLUMNcommands required for migrations between versions. For more information pleaseseehttp://www.sqlite.org/omitted.html

Sahara integration into OpenStack Dashboard¶

The sahara dashboard package has been deprecated in the Juno release. Thefunctionality of the dashboard has been fully incorporated into theOpenStack Dashboard. The sahara interface is available under the“Project” -> “Data Processing” tab.

The Data processing service endpoints must be registered in the Identityservice catalog for the Dashboard to properly recognize and displaythose user interface components. For more details on this process please seeregistering Sahara in installation guide.

Thesahara-dashboardproject is now used solely to host sahara user interface integration tests.

Virtual machine user name changes¶

The HEAT infrastructure engine has been updated to use the same rules forinstance user names as the direct engine. In previous releases the username for instances created by sahara using HEAT was always ‘ec2-user’. Asof Juno, the user name is taken from the image registry as described intheRegistering an Image document.

This change breaks backward compatibility for clusters created using the HEATinfrastructure engine prior to the Juno release. Clusters will continue tooperate, but we do not recommended using the scaling operations with them.

Anti affinity implementation changed¶

Starting with the Juno release the anti affinity feature is implementedusing server groups. From the user perspective there will be nonoticeable changes with this feature. Internally this change hasintroduced the following behavior:

1. Server group objects will be created for any clusters with anti affinityenabled.
2. Affected instances on the same host will not be allowed even if theydo not have common processes. Prior to Juno, instances with differingprocesses were allowed on the same host. The new implementationguarantees that all affected instances will be on different hostsregardless of their processes.

The new anti affinity implementation will only be applied for new clusters.Clusters created with previous versions will continue to operate underthe older implementation, this applies to scaling operations on theseclusters as well.

Sahara requires policy configuration¶

Sahara now requires a policy configuration file. Thepolicy.json fileshould be placed in the same directory as the sahara configuration file orspecified using thepolicy_file parameter. For more details about thepolicy file please see thepolicy section in the configuration guide.

Direct engine deprecation¶

In the Liberty release the direct infrastructure engine has been deprecated andthe heat infrastructure engine is now default. This means, that it ispreferable to use heat engine instead now. In the Liberty release you cancontinue to operate clusters with the direct engine (create, delete, scale).Using heat engine only the delete operation is available on clusters that werecreated by the direct engine. After the Liberty release the direct engine willbe removed, this means that you will only be able to delete clusters createdwith the direct engine.

Policy namespace changed (policy.json)¶

The “data-processing:” namespace has been added to the beginning of the allSahara’s policy based actions, so, you need to update the policy.json file byprepending all actions with “data-processing:”.

Note

Since Mitaka release sahara actively uses release notes so you can see allrequired upgrade actions here:http://docs.openstack.org/releasenotes/sahara/