Stein Series Release Notes¶

10.0.0¶

Added new tool sahara-status upgrade check.

New framework for sahara-status upgrade check command is added. This framework allows adding various checks which can be run before a Sahara upgrade to ensure if the upgrade can be performed safely.

Adding the ability to change default timeout parameter for ambari agent package installation

Users of Sahara’s APIv2 may request a microversion of that API, with “OpenStack-API-Version: data-processing [version]” in the request headers.

In Sahara APIv2, the type, availability zone, and locality of boot volumes may be expressed explicitly through the boot_volume_type, boot_volume_availability_zone, and boot_volume_local_to_instance parameters.

In an effort to improve Sahara’s usuability and manutenability we are splitting the plugins from Sahara core into their own repositories.

Operator can now use new CLI tool sahara-status upgrade check to check if Sahara deployment can be safely upgraded from N-1 to N release.

The default proxy role for Swift is now member instead of Member. Keystone now creates the former by default, even if the latter is recognized to be the same (case preserving).

With APIv2 we detected some inconsistencies on the policies. This patch updates the policy to fix those incosistencies.

The command hdfs fs has been deprecated in favor of hdfs fs. This fixes will allow the use of Hbase service.

This fixes the issue with NTP configuration where a prefered server provided by the user is added to the end of the file and the defaults are not deleted. Here we add the prefered server to the top of the file.

As part of the APIv2 work we changed all tenant_id references to project_id on the return payload of REST calls.

All APIv2 policy names have been changed to the recommended format: specifically, changes to resource names (now _singular_, whereas previously they may have been _plural_, or otherwise inconsistent), action verbs (now fully independent of HTTP semantics) and overall formatting (hyphens replace underscores). Eventually, the remaining non-conforming policy names will be deprecated too.

Some polishings to APIv2 have been made in an effort to bring it from experimental (and therefore, evolving and unpredictable) to stable. More instances of tenant_id have been changed to project_id, in the cluster and job template APIs. job_id was changed to job_template_id in the job API. The newly-minted query string validation feature has been fixed to allow show_progress as a parameter on cluster GET; on a similar note some APIv2 endpoints which previously could be filtered by hadoop_version are now filtered by plugin_version instead. Also, the schema for cluster PATCH in APIv1.1 now no longer includes the key update_keypair; its prior inclusion was a mistake.

In APIv2 there is now strict checking of parameters in the query string. This means that unexpected values in the query string will give a 400 error (as opposed to previously being ignored, or causing a 500 error).