Note di rilascio per la serie Stein



Aggiunto il nuovo strumento sahara-status upgrade check.

  • L’APIv2 di Sahara è ora considerata stabile e non più sperimentale.

Nuove funzionalità

  • È stata aggiunta una nuova infrastruttura per supportare il comando sahara-status upgrade check. Questa infrastruttura permette l’aggiunta di vari controlli che possono essere eseguiti prima di un aggiornamento di Sahara per assicurarsi che l’aggiornamento possa essere eseguito in sicurezza.

  • Aggiunta la capacità di cambiare il parametro predefinito di timeout per l’installazione del pacchetto dell’agente Ambari

  • Gli utenti dell’APIv2 di Sahara possono richiedere una specifica microversione dell’API tramite «OpenStack-API-Version: data-processing [versione]» nelle intestazioni della richiesta.

  • 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.

Note di aggiornamento

  • Gli operatori possono usare il nuovo strumento a riga di comando sahara-status upgrade check per verificare che l’intallazione di Sahara può essere aggiornata in sicurezza dalla versione N-1 alla N.

  • 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).

Correzione di bug

  • 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.

Altre note

  • 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).