Jump to: navigation, search

Difference between revisions of "Sahara/ReleaseNotes/Juno"

(New Key Features)
(Replaced content with "Moved to https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Data_Processing_.28Sahara.29")
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== New Key Features ===
+
Moved to https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Data_Processing_.28Sahara.29
 
 
* Data processing UI was fully merged into OpenStack Dashboard (horizon).
 
* Support of Cloudera Hadoop Distribution was added.
 
* Support of Apache Spark was added. Supported versions are 0.9.1 and 1.0.0. Elastic data processing (EDP) engine was refactored a lot to support non-Oozie workflow engines.
 
* Support of Apache Hadoop 2.4.1 was added in addition to existing 1.2.1 and 2.3.0. Version 2.3.0 is deprecated in Juno.
 
* Support of multi region deployments.
 
* Hadoop Swift authentication using keystone trust mechanism. Now Hadoop can access data in Swift without storing credentials in config files.
 
* Ceilometer integration was added. Now Sahara notifies Ceilometer about all cluster state changes.
 
* Cluster provisioning error handling was improved. If something goes wrong during scaling, cluster will rollback to original state.
 
* Added ability to specify security groups for each of node groups. Also Sahara could automatically create security group with only required ports open.
 
 
 
=== Known Issues ===
 
 
 
* [https://bugs.launchpad.net/sahara/+bug/1271349 Bug 1271349]: Sahara requires root privileges to access VMs via namespaces.
 
 
 
=== Upgrade Notes ===
 
 
 
==== Main binary renamed to sahara-all ====
 
 
 
Please, note that you should use `sahara-all` instead of `sahara-api` to start
 
the All-In-One Sahara.
 
 
 
==== sahara.conf upgrade ====
 
 
 
We've migrated from custom auth_token middleware config options to the common
 
config options. To update your config file you should replace the following
 
old config opts with the new ones.
 
 
 
* "os_auth_protocol", "os_auth_host", "os_auth_port" -> "[keystone_authtoken]/auth_uri" and "[keystone_authtoken]/identity_uri"
 
* "os_admin_username" -> "[keystone_authtoken]/admin_user"
 
* "os_admin_password" -> "[keystone_authtoken]/admin_password"
 
* "os_admin_tenant_name" -> "[keystone_authtoken]/admin_tenant_name"
 
 
 
We've replaced oslo code from sahara.openstack.common.db by usage of oslo.db library.
 
 
 
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.
 

Latest revision as of 08:38, 16 October 2014

Moved to https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Data_Processing_.28Sahara.29