Jump to: navigation, search

Difference between revisions of "ReleaseNotes/Havana/pt BR"

(Trove Databases)
(Orquestração OpenStack (Heat))
 
(41 intermediate revisions by 2 users not shown)
Line 321: Line 321:
 
O projeto Bases de dados como um serviço do OpenStack graduou-se da incubação no ciclo Havana, e graças à sua determinação eles entregaram um conjunto de painéis para o OpenStack dashboard para permitir o provisionamento e gerenciamento de suas bases de dados do Trove e backups. Declaração: Dado que a primeira versão oficial do Trove como um projeto integrado não será antes de IceHouse, esta funcionalidade deve ser considerada experimental e sujeita a mudanças.
 
O projeto Bases de dados como um serviço do OpenStack graduou-se da incubação no ciclo Havana, e graças à sua determinação eles entregaram um conjunto de painéis para o OpenStack dashboard para permitir o provisionamento e gerenciamento de suas bases de dados do Trove e backups. Declaração: Dado que a primeira versão oficial do Trove como um projeto integrado não será antes de IceHouse, esta funcionalidade deve ser considerada experimental e sujeita a mudanças.
  
===== Nova Features =====
+
===== Funcionalidades Nova =====
  
The number of OpenStack Compute (Nova) features that are supported in Horizon
+
O número de funcionalidades do OpenStack Compute (Nova) suportadas no Horizon continuam à crescer. Novas funcionalidades no ciclo Havana incluem:
continues to grow. New features in the Havana release include:
 
  
* Editable default quotas.
+
* Cotas padrão editáveis.
* The ability for an administrator to reset the password of a server/instance.
+
* Habilidade para um administrador resetar a senha de um servidor/instância.
* Availability zone support.
+
* Suporte à Zonas de disponibilidade.
* Improved region support.
+
* Suporte à regiões melhorado.
* Instance resizing.
+
* Redimensionamento de instâncias.
* Improved boot-from-volume support.
+
* Suporte ao boot de volume melhorado.
* Per-project flavor support.
+
* Suporte à flavors por projeto.
  
All of these provide a richer set of options for controlling where, when and how
+
Todos estes fornecem um conjunto mais rico de opções para controlar onde, quando e como as instâncias são disparadas, e melhora como elas são gerenciadas uma vez que estão rodando.
instances are launched, and improving how they're managed once they're up and
 
running.
 
  
===== Neutron Features =====
+
===== Funcionalidades Neutron =====
  
A number of important new OpenStack Networking (Neutron) features are showcased
+
Um número de novas funcionalidades do OpenStack Networking (Neutron) são exibidas na versão havana, mais notavelmente:
in the Havana release, most notably:
 
  
* VPN as a Service.
+
* VPN como um serviço.
* Firewall as a Service.
+
* Firewall como um serviço.
* Editable and interactive network topology visualizations.
+
* Visualização de topologia de rede editável e interativa.
* Full security group and quota parity between Neutron and Nova network.
+
* Paridade completa de grupos de segurança e cotas entre Neutron e Nova Network.
  
These features allow for tremendous flexibility when constructing
+
Estas funcionalidades permite uma tremenda flexibilidade quando se for construir redes definidas em sofware para sua nuvem utilizando Neutron.
software-defined networks for your cloud using Neutron.
 
  
==== User Experience Improvements ====
+
==== Melhorias de Experiência de Usuário ====
  
===== Self-Service Password Change =====
+
===== Troca de senha self-service =====
  
Empowered by changes to the Identity API v2.0 (Keystone), users can now change their own
+
Apoiado por mudanças na API de Identidade v2.0 (Keystone), usuários agora podem modificar suas próprias senhas sem a necessidades de envolver um administrador. Isto é mais seguro e menos trabalhoso para todos. Esta funcionalidade ainda não está disponível para usuários da API v3 de Identidade.
passwords without the need to involve an administrator. This is more secure and
 
takes the hassle out of things for everyone. This feature is not yet available to users of Identity API v3.
 
  
===== Better Admin Information Architecture =====
+
===== Melhor Arquitetura de Informação de Administração =====
  
Several sections of the Admin dashboard have been rearranged to more logically
+
Várias seções do dashboard de administração foram rearranjadas para agrupar mais logicamente a informação. Além disto, novas fontes de informação foram aducionadas permitindo aos administradores compreender melhor o estado dos hosts na nuvem e seu relacionamento com os agregados de host, zonas de disponibilidade, etc.
group information together. Additionally, new sources of information have been
 
added to allow Admins to better understand the state of the hosts in the cloud
 
and their relationship to host aggregates, availability zones, etc.
 
  
===== Improved Messaging To Users On Logout =====
+
===== Melhoria nas mensagens aos usuários no Logout =====
  
Several new indicators have been added to inform users why they've been logged
+
Vários novos indicadores foram adicionados para informar os usuários porque eles fora deslogados quando acabam na tela de login inesperadamente. Estes indicadores deixam claro se a sessão do usuário expirou, o tempo esgotou por inatividade, ou eles não estão autorizados para a seção do dashboard que tentaram acessar.
out when they land on the login screen unexpectedly. These indicators make it
 
clear whether the user's session has expired, they timed out due to inactivity,
 
or they are not authorized for the section of the dashboard they attempted to
 
access.
 
  
===== Security Group Rule Templates =====
+
===== Modelos de Regras de Grupos de Segurança =====
  
Since there are many very common security group rules which users tediously
+
Já que existem muitas regras de grupos de segurança bastante comuns que os usuários necessitam tediosamente readicionar cada vez (regras para SSH e ping, por exemplo) o time do Horizon adicionou modelos pré-configurados para regras comuns que um usuário pode selecionar e adicionar ao seu grupo de segurança com dois cliques. Estas regras são configuráveis através das definições SECURITY_GROUP_RULES.
re-add each time (rules for SSH and ping, for example) the Horizon team has
 
added pre-configured templates for common rules which a user can select and
 
add to their security group with two clicks. These rules are configurable
 
via the SECURITY_GROUP_RULES setting.
 
  
==== Community ====
+
==== Comunidade ====
  
 
===== Time de Tradução =====
 
===== Time de Tradução =====
Line 388: Line 370:
 
As traduções do OpenStack vieram com tudo neste ciclo Havana e a qualidade das traduções no Horizon são as melhores até agora, de longe. Parabéns ao time por seu sucesso em construir a comunidade que começou primariamente dentro do projeto OpenStack Dashboard.
 
As traduções do OpenStack vieram com tudo neste ciclo Havana e a qualidade das traduções no Horizon são as melhores até agora, de longe. Parabéns ao time por seu sucesso em construir a comunidade que começou primariamente dentro do projeto OpenStack Dashboard.
  
===== User Experience Group =====
+
===== Grupo de Experiência de Usuário =====
  
A fledgling OpenStack User Experience Group formed during the Havana cycle with
+
Um novo grupo de Experiência de Usuário do OpenStack se formou durante o ciclo Havana com a missão de melhor a UX por todo o OpenStack. Eles rapidamente se tornaram indispensáveis no processo de projetar e melhorar funcionalidades no OpenStack Dashboard. Espere melhoria futura significante na Experiência de Usuário agora que existem pessoas dedicadas ativamente colaborando para aumentar o patamar.
the mission of improving UX throughout OpenStack. They have quickly made
 
themselves indispensable to the process of designing and improving features in
 
the OpenStack Dashboard. Expect significant future improvement in User
 
Experience now that there are dedicated people actively collaborating in the
 
open to raise the bar.
 
  
==== Under The Hood ====
+
==== Embaixo do capô ====
  
===== Less Complicated LESS Compilation: No More NodeJS =====
+
===== Compilação LESS menos complicada: Sem NodeJS =====
  
Due to outcry from various parties, and made possible by improvements in the
+
Devido à solicitações de várias partes, e possível por melhorias no suporte da comunidade Python ao LESS, Horizon removeu todos os traços de NodeJS do projeto. Agora nõs utilizamos o módulo lesscpy para compilar nosso LESS na página de estilos final. Isto não deve afetar a maioria dos usuários de maneira alguma, mas facilita a vida para distribuições downstream similares.
Python community's support for LESS, Horizon has removed all traces of NodeJS
 
from the project. We now use the lesscpy module to compile our LESS into
 
the final stylesheets. This should not affect most users in any way, but it
 
should make life easier for downstream distributions and the like.
 
  
===== Role-Based Access Controls =====
+
===== Controle de Acesso Baseado em Papéis =====
  
Horizon has begun the transition to using the other OpenStack projects'
+
Horizon começou a transição para o uso dos arquivos policy.json de outros projetos do OpenStack para reforçar o controle de acesso no dashboard se os arquivos forem fornecidos. Isto significa que os controles de acesso são mais configuráveis e podem ser mantidos em sincronia entre o projeto original e Horizon. Atualmente isto só é suportado para o Keystone e partes dos arquivos de políticas do Nova. Suporte total virá na próxima versão. Você irá precisar setar as definições de POLICY_FILES_PATH e POLICY_FILES para habilitar esta funcionalidade.
policy.json files to enforce access controls in the dashboard if the files
 
are provided. This means access controls are more configurable and can be kept
 
in sync between the originating project and Horizon. Currently this is only
 
supported for Keystone and parts of Nova's policy files. Full support will
 
come in the next release. You will need to set the POLICY_FILES_PATH and
 
POLICY_FILES settings in order to enable this feature.
 
  
==== Other Improvements and Fixes ====
+
==== Outras Melhorias e Correções ====
  
* Swift container and object metadata are now supported.
+
* Contêiner Swift e metadados de objetos são agora suportados.
* New visualizations for utilization and quotas.
+
* Novas visualizações para utilização e cotas.
* The Cisco N1K Router plugin's additional features are available through a special additional dashboard when enabled and supported in Neutron.
+
* As funcionalidade adicionais do plugin do Roteador Cisco N1K estão disponíveis através de um dashboard adicional especial quando habilitado e suportado no Neutron.
* Support for self-signed or other specified SSL certificate checking.
+
* Suporte para verificação de certificados SSL auto-assinados ou outros especificados.
* Glance image types are now configurable.
+
* Tipos de imagens Glance agora são configuráveis.
* Sorting has been improved in many places through the dashboard.
+
* Ordenação foi melhorada em muitos locais através do dasboard.
* API call efficiency optimizations.
+
* Otimizações na eficência de chamadas de API.
* Required fields in forms are now better indicated.
+
* Campos requeridos em formulários agora são melhor indicados.
* Session timeout can now be enabled to log out the user after a period of inactivity as a security feature.
+
* Tempo limite de sessão agora pode ser habilitado para deslogar o usuário após um período de inatividade para maior segurança.
* Significant PEP8 and code quality compliance improvements.
+
* Melhorias significantes de concordância PEP8 e de qualidade de código.
* Hundreds of bugfixes and minor user experience improvements.
+
* Centenas de correções de bugs e melhorias menores de experiência de usuário.
  
=== Upgrade Information ===
+
=== Informação de Atualização ===
  
==== Allowed Hosts ====
+
==== Hosts Permitidos ====
  
For production deployments of Horizon you must add the ALLOWED_HOSTS
+
Para implantação em produção do Horizon você deve adicionar a definição ALLOWED_HOSTS no seu arquivo settings.py ou local_settings.py. Esta definição foi adicionada no Django 1.5 e é uma funcionalidade de segurança importante. Para mais informação sobre isto por favor consulte o arquivo de exemplo local_settings.example.py ou a documentação do Django.
setting to your settings.py or local_settings.py file. This setting
 
was added in Django 1.5 and is an important security feature. For more
 
information on it please consult the local_settings.py.example file
 
or Django's documentation.
 
  
==== Enabling Keystone and Neutron Features ====
+
==== Habilitando Funcionalidades Keystone e Neutron ====
  
If you have existing configurations for the OPENSTACK_KEYSTONE_BACKEND
+
Se você possui configurações existentes para a definição OPENSTACK_KEYSTONE_BACKEND ou OPENSTACK_NEUTRON_NETWORK, você vai querer consultar o arquivo local_settings.example.py por informações das novas opções que foram adicionadas. Configurações existentes continuarão funcionando, mas não terão as chaves corretas para habilitar algumas das novas funcionalidades do Havana.
or OPENSTACK_NEUTRON_NETWORK settings, you will want to consult the
 
local_settings.example.py file for information on the new options that
 
have been added. Existing configurations will continue to work, but may not
 
have the correct keys to enable some of the new features in Havana.
 
  
=== Known Issues and Limitations ===
+
=== Problemas Conhecidos e Limitações ===
  
==== Session Creation and Health Checks ====
+
==== Criação de Sessão e Verificação de saúde ====
  
If you use a health monitoring service that pings the home page combined with
+
Se você utiliza um serviço de monitoramento de saúde que pinga a página inicial combinado com um backend de sessão apoiado por uma base de dados, você pode encontrar criação de sessões excessivas. Este problema está relacionado para ser corrigido em breve, mas neste meio tempo a solução recomentada é escrever um job periódico que exclui as sessões expiradas do seu armazenamento de sessões regularmente.
a database-backed session backend you may experience excessive session creation.
 
This issue is slated to be fixed soon, but in the interim the recommended
 
solution is to write a periodic job that deletes expired sessions from your
 
session store on a regular basis.
 
  
==== Deleting large numbers of resources simultaneously ====
+
==== Excluir um grande número de recursos simultâneamente ====
  
Using the "select all" checkbox to delete large numbers of resources at once
+
Utilizar a caixa "selecionar tudo" para excluir um grande número de recursos de uma única vez pode atingir o tempo limite de rede (dependendo da configuração). Isto deve-se às APIs por baixa não suportarem a exclusão em lote nativamente, e consequentemente o Horizon precisa enviar requisições de exclusão para cada recurso indivudualmente nos bastidores.
can cause network timeouts (depending on configuration). This is due to the
 
underlying APIs not supporting bulk-deletion natively, and consequently Horizon
 
has to send requests to delete each resource individually behind the scenes.
 
  
==== Conflicting Security Group Names With Neutron ====
+
==== Nomes de Grupos de Segurança Conflitantes com Neutron ====
  
Whereas Nova Network uses only the name of a security group when specifying
+
Sempre onde Nova Network utiliza apenas o nome de um grupo de segurança quando especifica grupos de segurança no momento de disparar uma instância, Neutron pode aceitar tanto um nome quanto UUDI. Para suportar ambos , o Horizon passa o nome do grupo de segurança selecionado. Entratanto, devido à alguns problemas de isolamento de dados no Neutron existe um problema que pode surgir se um usuário administrador tentar especificar um grupo de segurança com o mesmo nome de outro grupo de segurança em um projeto que ele também possui acesso. Neutron irá encontrar múltiplas ocorrências para o grupo de segurança e irá falhar ao disparar a instância. A maneira de contornar isto é tratar os nomes de grupos de segurança como únicos para todos usuários administradores.
security groups at instance launch time, Neutron can accept either a name or
 
a UUID. In order to support both, Horizon passes in the name of the selected
 
security groups. However, due to some data-isolation issues in Neutron there is
 
an issue that can arise if an admin user tries to specify a security group with
 
the same name as another security group in a different project which they also
 
have access to. Neutron will find multiple matches for the security group
 
name and will fail to launch the instance. The current workaround is to treat
 
security group names as unique for admin users.
 
  
=== Backwards Compatibility ===
+
==== Gráficos quebrados para recursos não computacionais ====
  
The Havana Horizon release should be fully compatible with both Havana and
+
Os gráficos de linha da página de utilização de recursos não exibe recursos não computacionais quando se escolhe agrupar por -- https://bugs.launchpad.net/horizon/+bug/1243796
Grizzly versions of the rest of the OpenStack integrated projects (Nova, Swift,
 
etc.). New features in other OpenStack projects which did not exist in Grizzly
 
will obviously only work in Horizon if the rest of the stack supports them as
 
well.
 
  
Overall, great effort has been made to maintain compatibility for
+
=== Retrocompatibilidade ===
third-party developers who have built on Horizon so far.
 
  
== OpenStack Identity (Keystone) ==
+
A versão Horizon Havana deve ser totalmente compatível tanto com Havana quanto com Grizzly do restante dos projetos integrados do OpenStack (Nova, Swift, etc.) Novas funcionalidades em outros projetos OpenStack qe não existiam em Grizzly irão obviamente funcionar no Horizon apenas se o resto da pilha suportar elas também.
  
=== Key New Features ===
+
Em geral, um grande esforço foi realizado para manter compatibilidade para desenvolvedores terceiros que construíram sobre o Horizon até agora.
  
* Improved deployment flexibility
+
== Identidade OpenStack (Keystone) ==
** Authorization data (tenants/projects, roles, role assignments; e.g. SQL) can now be stored in a separate backend, as determined by the "assignments" driver, from authentication data (users, groups; e.g. LDAP), as determined by the "identity" driver
 
** Credentials (e.g. ec2 tokens) can now be stored in a separate backend, as determined by the "credentials" driver, from authentication data
 
** Ability to specify more granular RBAC policy rules (for example, based on attributes in the API request / response body)
 
** Pluggable handling of external authentication using <code>REMOTE_USER</code>
 
** Token generation, which is currently either UUID or PKI based, is now pluggable and separated from token persistence. Deployers can write a custom implementation of the <code>keystone.token.provider.Provider</code> interface and configure keystone to use it with <code>[token] provider</code>. As a result, <code>[signing] token_format</code> is now deprecated in favor of this new configuration option.
 
** First-class support for deployment behind Apache httpd
 
  
* New deployment features
+
=== Principais Novas Funcionalidades ===
** Ability to cache the results of driver calls in a key-value store (for example, memcached or redis)
 
** <code>keystone-manage token_flush</code> command to help purge expired tokens
 
  
* New API features
+
* Flexibilidade de implantação melhorada.
** Delegated role-based authorization to arbitrary consumers using OAuth 1.0a
+
** Dados de autorização (tenants/projetos, papéis, atribuição de papéis; ex: SQL) agora podem ser armazenadas em um backend separado, como determinado pelo controlador de "atribuições", a partir dos dados de autenticação (usuários, grupos; ex: LDAP), como determinado pelo controlador de "identidade".
** API clients can now opt out of the service catalog being included in a token response
+
** Credenciais (ex: tokens EC2) agora podem ser armazenados em um backend separado conforme determinado pelo controlador de "credenciais", a partir dos dados de autenticação.
** Domain role assignments can now be inherited by that domain's projects
+
** Habilidade de especificar políticas RBAC mais granulares (por exemplo, basedas em atributos da requisição / corpo de resposta da API).
** Aggregated role assignments API
+
** Manipulação plugável de autenticação externa utilizando <code>REMOTE_USER</code>.
** External authentication providers can now embed a binding reference into tokens such that remote services may optionally validate the identity of the user presenting the token against an presented external authentication mechanism. Currently, only <code>kerberos</code> is supported.
+
** Geração de token, que atualmente é baseada em UUID ou PKI, é agora plugável e separada da persistância de token. Implantadores podem escrever uma implementação customizada da interface <code>keystone.token.provider.Provider</code> e configurar o keystone para utilizar ele com <code>[token] provider</code>. Como resultado, <code>[signing] token_format</code> é agora deprecado em favor desta nova opção de configuração.
** Endpoints may now be explicitly mapped to projects, effectively preventing certain endpoints from appearing in the service catalog for certain based on the project scope of a token. This does not prevent end users from accessing or using endpoints they are aware of through some other means.
+
** Suporte de primeira classe para a implantação atrás de Apache httpd.
  
* Event notifications emitted for user and project/tenant create, update, and delete operations
+
* Novas funcionalidades de implantação.
* General performance improvements
+
** Habilidade de armazenar em cache os resultados de chamadas de controlador em um armazenamento chave-valor (por exemplo memcached ou redis).
* The v2 and v3 API now use the same logic for computing the list of roles assigned to a user-project pair during authentication, based on user+project, group+project, user+domain-inherited, and group+domain-inherited role assignments (where domain-inherited role assignments allow a domain-level role assignment to apply to all projects owned by that domain). The v3 API now uses a similar approach for computing user+domain role assignments for domain-scoped tokens.
+
** Comando <code>keystone-manage token_flush</code> para ajudar a limplar tokens expirados.
* Logs are handled using a common logging implementation from Oslo-incubator, consistent with other OpenStack projects
 
* SQL migrations for extensions can now be managed independently from the primary migration repository using <code>keystone-manage db_sync --extension=&laquo;extension-name&raquo;</code>.
 
  
=== Known Issues ===
+
* Novas funcionalidade de API.
 +
** Autorização delegada baseada em papéis para consumidores arbitrários utilizando OAUTH 1.0a.
 +
** Clientes de API agora pode escolher remover o catálogo de serviços incluído em uma resposta de token.
 +
** Atribuição de papéis de domínio podem agora ser herdadas pelo domínio do projeto.
 +
** API de atribuição de papéis agregados.
 +
** Provedores de autenticação externa agora podem embutar uma referência de ligação nos tokens para que serviços remotos possam opcionalmente validar a identidade do usuário apresentando o token contra um mecanismo de autenticação externo. Atualmente, apenas <code>kerberos</code> é suportado.
 +
** Endpoints agora podem ser explicitamente mapeados para projetos, efetivamente prevenindo certos endpoints de aparecerem no catálogo de serviços baseado no escopo do token do projeto. Isto não previne usuários de acessar ou utilizar endpoints que eles conhecem através de outros meios.
  
* [https://pypi.python.org/pypi/six/ six] v1.4.1 or higher is an undocumented requirement ([https://bugs.launchpad.net/keystone/+bug/1237089 bug 1237089]). Without six, Keystone will fail on startup with either <code>ImportError: No module named six</code> or <code>pkg_resources.DistributionNotFound: six</code>.
+
* Notificações de eventos emitidas para operações de criação, atualização e exclusão de usuários e projeto/tenant
* An experimental implementation of [https://blueprints.launchpad.net/keystone/+spec/multiple-ldap-servers domain-specific identity backends] (for example, a unique LDAP configuration per domain) was started in Havana but remains incomplete and will be finished during Icehouse.
+
* Melhorias gerais de performance
* With the LDAP assignment backend, attempting to unassigned role from a user that does not actually have that role, inadvertently assigns the role to the user instead (see [https://bugs.launchpad.net/keystone/+bug/1242855 bug 1242855])
+
* A API v2 e v3 agora utilizam a mesma lógica para computar a lista de papéis atribuídos a um par usuário-projeto durante a autenticação, baseado nas atribuições de papéis usuário+projeto, grupo+projeto, usuário+herança de domínio, e grupo+herança de domínio (onde atribuições de papel por herança de domínio permite uma atribuição de papéis em nível de domínio para aplicar em todos projetos do domínio). A API v3 agora utiliza uma abordagem similiar para computar as atribuições de papel para token de escopo de domínio.
 +
* Logs são manipulados utilizando uma implementação comum de logging do incubador Oslo, consistente com outros projetos do OpenStack.
 +
* Migrações de SQL para extensões podem agora ser gerenciadas independentemente do repositório de migração primária utilizando <code>keystone-manage db_sync --extension=&laquo;extension-name&raquo;</code>.
  
== OpenStack Network Service (Neutron) ==
+
=== Problemas Conhecidos ===
=== Key New Features ===
 
==== New Name ====
 
The OpenStack Networking project has a new name in this release: Neutron.  The Havana release will run using configuration files from Grizzly Quantum; however the usage of Quantum is deprecated and deployers should update all references at their earliest opportunity.  Support for the Quantum configuration files and executable names will dropped in 2014.1 (Icehouse).
 
==== Advanced Services ====
 
Neutron added two new advanced services during the latest development cycle and revised the load balancer service.
 
  
'''Load Balancer (LBaaS)''' Previously released as experimental features the in 2013.1 (Grizzly) release, the load balancing service and API extensions are now suitable for deployment. This release ships an updated API and with HAProxy driver support. Vendor drivers are expected in Icehouse and Radware has already made an out of tree Havana compatible driver available for download. The load balancing service can run on multiple network nodes.
+
* [https://pypi.python.org/pypi/six/ six] v1.4.1 ou maior é um requisito não documentado ([https://bugs.launchpad.net/keystone/+bug/1237089 bug 1237089]). Sem o six, o Keystone irá falhar na inicialização com <code>ImportError: No module named six</code> ou <code>pkg_resources.DistributionNotFound: six</code>.
 +
* Uma implementação experimental de [https://blueprints.launchpad.net/keystone/+spec/multiple-ldap-servers domain-specific backends de identidade] (por exemplo, uma configuração de LDAP única por domínio) foi iniciada em Havana mas permanece incompleta e será finalizada durante Icehouse.
 +
* Com o backend de atribuição LDAP, tentar remover um papel de um usuário que na verdade não o possui, acaba indvertidamente atribuindo o role ao usuário em vez disto (veja [https://bugs.launchpad.net/keystone/+bug/1242855 bug 1242855])
  
'''VPN (VPNaaS)''' Site-to-Site IPSec VPNs are now supported via the VPN service plugin.  The VPN API supports IPSec and and L3 agent ships with an OpenSwan driver.
+
== Serviço de Rede do OpenStack (Neutron) ==
 +
=== Principais Novas Funcionalidades ===
 +
==== Novo Nome ====
  
'''Firewall (FWaas)'''A new edge firewall service is included in this release. The firewall service enable tenant to configure security in depth as rules can be applied both at the edge via the firewall API and    on the VIF via the security group API. The FWaaS API and drivers are considered experimental as the Neutron will continue development during the next release cycle.  The team  welcomes community feedback on this extension.
+
O projeto de rede do OpenStack possui um novo nome nesta versão: Neutron. A versão Havana vai rodar utilizando arquivos de configuração do Quantum Grizzly; entretanto o uso do Quantum está deprecado e implantadores devem atualizar todas referências o mais breve possível. Suporte para os arquivos de configuração do Quantum e nomes de executáveis serão descartados em 2014.1 (Icehouse).
==== New Plugins ====
+
==== Serviços Avançados ====
'''Modular Layer 2 (ML2)''' The Modular Layer 2 (ML2) plugin is a new OpenSource plugin to Neutron. This plugin is a framework allowing OpenStack Networking to simultaneously utilize the variety of layer 2 networking technologies found in complex real-world data centers. It currently works with the existing Open vSwitch, Linux Bridge, and L2 agents.  The ML2 plugin supports local, flat, VLAN, GRE and VXLAN network types via a type drivers and different mechanism drivers.  There are vendor drivers available for Arista, Cisco Nexus, Hyper-V, and Tail-f NCS.  ML2 is a replacement for the Linux Bridge and Open vSwitch plugins which are now considered deprecated. [https://wiki.openstack.org/wiki/Neutron/ML2 More ML2 information]
+
Neutron adicionou dos novos serviços avançados durante o último ciclo de desenvolvimento e revisou o serviço de balanceamento de carga.
  
==== Other Features ====
+
'''Load Balancer (LBaaS)''' anteriormente lançado como uma funcionalidade experimental na versão 2013.1 (Grizzly), o serviço de balanceamento de carga e as extensões de API agora são adequadas para implantação. Esta versão inclui uma API atualizada e com suporte ao controlador HAProxy. Controladores de fabricantes são esperados na Icehouse e Radware já liberou três controladores compatíveis com Havana para download. O serviço de balanceamento de carga pode rodar em múltiplos nodos de rede.
* Support for PXE Boot Options in when creating a port
 
* Improved translation support
 
  
=== Known Issues ===
+
'''VPN (VPNaaS)''' VPNs IPSec Site-a-Site são agora suportadas via o plugin de serviço VPN. A API VPN suporta IPSec e agente L3 e inclui um controlador OpenSwan.
==== Upgrades from Grizzly ====
 
Starting the neutron-server after upgrading code, but prior to migration will result in some database models being created without the proper migrations occurring.  The following upgrade setups should be taken to ensure a properly upgraded database.
 
* Ensure that the database is stamped for Grizzly prior to stopping service.<code>quantum-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini stamp grizzly</code>
 
* Stop quantum-server and deploy the Neutron code '''Do not start the neutron-server at this time'''.
 
* Run Havana Migration <code>neutron-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini upgrade havana</code>
 
* Start neutron-server
 
  
==== Agents May Report a Different Host Name ====
+
'''Firewall (FWaas)''' Um novo serviço de firewall de borda foi incluído nesta versão. O serviço de firewall permite que um tenant configure em detalhes a seguranças já que as regras podem ser aplicadas tanto na API de firewall e no VIF via a API de grupo de segurança. a API FWaaaS e controladores são considerados experimentais e o Neutron irá continuar o desenvolvimento durante o próximo ciclo de versão. O time agradece o feedback da comunidade para estas extensões.
Neutron switched the method to determine a host's name from using the host's FQDN to the result returned by the gethostname(2) call. The change was made to be consistent with the rest of OpenStack. The hostname reported by an agent may be different and will change after the agents are updated to Havana. If so, it is necessary to reschedule all networks onto the new L3 and DHCP agent names to restore service.  The change will results in a brief data plane outage will while the deployer reschedules the network.
 
  
==== L3 Agent No Longer Defaults to Sending Gratuitous ARPs ====  
+
==== Novos Plugins ====
The L3 Agent previous defaults to sending gratuitous ARPs.  The calls to send the gratuitous ARPs cause kernel panics when deployed using network namespaces on some distributions.  Deployers may enable gratuitous ARP by setting ''send_arp_for_ha=3'' in the L3 Agent's configuration file.
+
'''Modular Layer 2 (ML2)''' O plugin Modular Layer 2 (ML2) é um novo plugin OpenSource para o Neutron. Este plugin é um framework que permite que a o serviço de rede do OpenStack utilize simultâneamente uma variedade de tecnologias de rede de camada 2 encontradas em data centers complexos do mundo real. Atualmente funciona com Open vSwitch, Linux Bridge e agentes L2. O plugin ML2 suporta tipos de rede local, flat, VLAN, FRE e VXLAN via controladores de tipo e controladores de mecanismo diferente. Existem controladores de fabricantes para Arista, Cisco Nexus,Hyper-V e Tail-f NCS.  ML2 é um substituto para plugins Linux Bridge e Open vSwitch que agora são considerados deprecados. [https://wiki.openstack.org/wiki/Neutron/ML2 Mais informações sobre ML2]
  
==== Firewall as a Service ====
+
==== Outras Funcionalidades ====
The experimental FWaaS API extension only supports one active policy per tenant.  The behavior will change in the during the Icehouse development cycle to allow for different policies to be attached to different tenant routers.
+
* Suporte para opções de boot PXE quando criando uma porta
 +
* Suporte melhorado de tradução
  
=== Upgrade Notes ===
+
=== Problemas Conhecidos ===
* Changes to neutron-dhcp-agent require you to first upgrade your dhcp-agents. Then wait until the dhcp_lease time has expired. After waiting at least dhcp_lease time, update neutron-server. Failure to do this may lead to cases where an instance is deleted and the dnsmasq process has not released the lease and neturon allocates that ip to a new port. (https://review.openstack.org/#/c/37580/)
+
==== Atualizações do Grizzly ====
 +
Iniciar o neutron-server após atualizar o código, mas antes da migração irá resultar em alguns modelos de base de dados serem criados sem a correta migração. As seguintes definições de atulização devem ser realizadas para garantir uma base de dados corretamente atualizada.
 +
* Certifique-se que a base de dados aponta para Grizzly antes de parar o serviço. <code>quantum-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini stamp grizzly</code>
 +
* Pare o quantum-server e implante o código Neutron "Não inicie o neutron-server neste momento"
 +
* Rode o código de migração do Havana <code>neutron-db-manage --config-file /caminho/para/quantum.conf --config-file /caminho/para/plugin/conf.ini upgrade havana</code>
 +
* Inicie o neutron-server
  
*  There is a new default policy.json file. Deployers with existing deployments should update their files as many options have changed: [http://git.openstack.org/cgit/openstack/neutron/plain/etc/policy.json policy.json]
+
==== Agentes Podem Reportar um Host Name Diferente ====
 +
Neutron mudou a maneira de determinar o nome do host de utilizar o FQDN do host para o resultado retornado pela chamada gethostname(2). A Alteração foi feita para ser consistente com o resto do OpenStack. O hostname reportado por um agente pode ser diferente e irá mudar após a atualização dos agentes para Havana. Sendo assim, é necessário reagendar todas redes para os novos nomes de agente l3 e DHCP para reestabelecer o serviço. Esta mudança irá resultar em uma breve interrupçõa dos dados enquanto o implantador reagenda a rede.
  
=== Deprecation Notices ===
+
==== Agente L3 Não Envia Mais ARPs Gratuitos por Padrão ====  
* The usage of "quantum" or "Quantum" in configuration files and executable names is officially deprecated. This is the last release that will support those names and new deployments should use proper Neutron names for those values. Support for compatibility will only exist in this release.
+
O padrão anterior do agente L3 era enviar ARPs gratuitos. As chamadas para enviar ARPs gratuitos causavam pânicos no kernel quando implantadas utilizando namespaces de rede em algumas distribuições. Implantadores podem habilitar ARP gratuiro definindo ''send_arp_for_ha=3'' no arquivo de configuração do agente L3.
* The Linux Bridge and Open vSwitch plugins have been feature frozen and will be removed in the J (2014.2) release.  New deployments should choose ML2 instead of the individual Open vSwitch or Linux Bridge plugins.
 
  
== OpenStack Block Storage (Cinder) ==
+
==== Firewall como um Serviço ====
 +
As extensões de API experimental FWaaS suporta apenas uma politica ativa por tenant. O comportamento irá mudar durante o ciclo de desenvolvimento Icehouse para permitir diferentes políticas serem anexadas em diferentes roteadores de tenant.
  
=== Key New Features ===
+
=== Notas de Atualização ===
* Volume migration - admin API to migrate a volume to a different Cinder back-end
+
* Alterações no neutron-dhcp-agent requerem que você primeiro faça o upgrade dos dhcp-agents. Então esperar até o tempo de dhcp_lease expirar. Após isto, atualizar o neutron-server. Falhar ao fazer isto pode levar à casos onde uma instância é excluída e o processo dnsmasq não liberou o IP e o neutron aloca aquele IP para uma nova porta. (https://review.openstack.org/#/c/37580/)
* Scheduler hints extension added to V2 API
 
* Added local block storage driver to allow use of raw disks without LVM
 
* Added ability to extend the size of an existing volume
 
* Added ability to transfer volume from one tenant to another
 
* Added API call to enable editing default quota settings
 
* Added config option to allow auto-flatten snapshots for back-ends that leave a dependency when creating volume from snapshot
 
* Allow API to accept a "host-name" in the volume-attach and not just an instance uuid
 
* Enable the generalized backup layer to allow backups from any iSCSI device that doesn't have internal optimizations
 
* Added Ceph driver to backup service (allowing Ceph as a backup target with differential backups from Ceph to Ceph)
 
* Added rate-limiting information to provider info that can be passed to Nova and used by the hyper-visor
 
* New Windows Storage Server driver features ([https://blueprints.launchpad.net/cinder/+spec/windows-storage-driver-extended blueprint])
 
  
=== New Vendor Drivers ===
+
* Existe um novo arquivo policy.json. Implantadores com implantações existentes deve atualizar seus arquivos pois muitas opções mudaram. [http://git.openstack.org/cgit/openstack/neutron/plain/etc/policy.json policy.json]
* Dell EqualLogic volume driver
 
* VMware VMDK cinder driver
 
* IBM General Parallel File System (GPFS)
 
  
=== Major Additions To Existing Drivers ===
+
=== Avisos de Deprecação ===
* Add Fibre Channel drivers for Huawei storage systems
+
* O uso de "quantum" ou "Quantum" em arquivos de configuração e nomes de executáveis está oficialmente deprecado. Esta é a última versão que irá suportar estes nomes e novas implantações devem utilizar nomes Neutron adequados para estes valores. Suporte para compatiblidade irá existir apenas nesta versão.
* Add a NFS Volume Driver to support Nexenta storage in Cinder
 
* Misc updates, and device specific adds to existing drivers have also been made to almost every existing vendor driver
 
* Optimized volume migration for IBM Storwize driver
 
  
=== New Backup Drivers ===
+
* Os plugin de Linux Bridge e Open vSwitch foram congelados em termos de novas funcionalidades e serão removidos na versão J (2014.1). Novas implantações devem escolher ML2 em vez dos plugins individuais Linux Bridge e Open vSwitch.
* Allow Ceph as an option for volume backup
 
* IBM Tivoli Storage Manager (TSM)
 
  
=== Known Issues ===
+
== Armazenamento de Bloco OpenStack (Cinder) ==
* Bug #1237338 : Upload volume to image fails with VMWare volume driver
 
* Bug: #1240299 : clear volume operation is called on all LVM vol deletes even thin provisioned. Until fix is released be sure to set volume_clear=None in cinder.conf
 
  
=== Upgrade Notes ===
+
=== Principais Novas Funcionalidades ===
* The ThinLVM volume driver functionality is now part of the standard LVM ISCSI volume driver.  Configuration should be updated to use volume_driver="cinder.volume.drivers.lvm.LVMISCSIDriver" and set the option lvm_type="thin".  This will be done automatically for compatibility in Havana if volume_driver is set to "cinder.volume.drivers.lvm.ThinLVMVolumeDriver", but Icehouse will require these options to be updated in cinder.conf.
+
* Migração de Volume - API de admin para migrar um volume para um backend Cinder diferente
 +
* Extensão de dicas do agendador adicionada na API V2
 +
* Adicionado controlador de armazenamento de bloco local para permitir o uso de discos raw sem LVM
 +
* Adicionada habilidade de estender o tamanhho de um volume existente
 +
* Adicionada habilidade de transferir volumes de um tenant para outro
 +
* Adicionada chamada de API para habilitar a edição da definição de cota padrão
 +
* Adicionada opção de configuração para permitir auto-flatten de snapshots para backends que deixam uma dependência quando criam volumes de snapshot.
 +
* Adicionada API para aceitar um nome de host na anexação de volume e não apenas um UUID de instância
 +
* Habilita a camada de backup generalizada para permitir backups de qualquer dispositivo iSCSI que não possui otimizações internas
 +
* Adicionado controlador Ceph para serviço de backup (permitindo Ceph como um destino de backup com backups diferenciais de Ceph para Ceph)
 +
* Adicionada informação de limitação de taxa para fornecer informações que podem ser passadas para Nova e utilizadas pelo hypervisor
 +
* Novas funcionalidades do Servidor de Armazenamento Windows ([https://blueprints.launchpad.net/cinder/+spec/windows-storage-driver-extended blueprint])
  
== OpenStack Metering (Ceilometer) ==
+
=== Controladores de Novos Fabricantes ===
=== Key New Features ===
+
* Controlador de volume Dell EqualLogic
 +
* Controlador Cinder VMware VMDK
 +
* Sistema de arquivos IBM General Parallel File System (GPFS)
 +
 
 +
=== Principais Novidades dos Controladores Existentes ===
 +
* Adicionados Controladores Fibre Channel para sistemas de armazenamento Huawei
 +
* Adicionado um Controlador de Volume NFS para suportar armazenamento Nexenta no Cinder
 +
* Atualizações de miscelânea, e adições específicas de dispositivos aos controladores existentes também foram realizadas para quase todos controladores de fabricantes existentes
 +
* Otimizada a migração de volume para o controlador IBM Storwize
 +
 
 +
=== Novos Drivers de Backup ===
 +
* Permitir Ceph como uma opção para backup de volume
 +
* Gerenciador de Armazenamento IBM Tivoli Storage Manager (TSM)
 +
 
 +
=== Problemas Conhecidos ===
 +
* Bug #1237338 : Upload de volume para imagem falha com controlador de volume VMWare
 +
* Bug: #1240299 : Operação de limpeza de volume é chamada em todas exclusões de LVM mesmo com provisionamento thin. Até a correção, certifique-se de definir volume_clear=None em cinder.conf
 +
 
 +
=== Notas de Atualização ===
 +
* A funcionalidade do driver de volume ThinLVM agora faz parte do driver padrão de volume ISCSI LVM. A configuração deve ser atualizado para usar volume_driver = "cinder.volume.drivers.lvm.LVMISCSIDriver" e defina a opção lvm_type = "thin". Isto será feito automaticamente para compatibilidade com Havana se a opção volume_driver é definida como "cinder.volume.drivers.lvm.ThinLVMVolumeDriver", mas a versão Icehouse exigirá que estas opções sejam atualizadas em cinder.conf.
 +
 
 +
== Medição OpenStack (Ceilometer) ==
 +
=== Principais Novas Funcionalidades ===
 
==== API ====
 
==== API ====
* The statistics endpoint can now be used to group samples by some fields using the ''groupby'' argument
+
* O endpoint de estatísticas pode agora ser utilizado para agrupar amostras por alguns campos utilizando o argumento "groupby"
* A new alarm API is now available (see '''Alarms''')
+
* Uma nova API de alarmes agora está dispon´viel (veja "Alarmes")
* Users can now post their own samples and meters through the API
+
* Usuários agora podem publicar suas próprias amostras e medidores através da API.
  
==== Alarms ====
+
==== Alarmes ====
Alarms are a new feature allowing users and operators to trigger actions based on comparing the statistics trend against a threshold over a period of time. It is composed of the following services:
+
Alarmes são uma nova funcionalidade que permite aos usuários e operadores disparar ações baseadas na comparação de tendências de estatísticas contra um limite durante um período de tempo. Eles são compostos dos seguintes serviços:
* ''ceilometer-api'' now exposes the new ''/v2/alarms'' endpoint providing control over alarm lifecycle;
+
* ''ceilometer-api'' agora expõe o novo endpoint ''/v2/alarms'' fornecendo controle sobre o ciclo de vida dos alarmes;
* ''ceilometer-alarm-evaluator'' evaluates alarms periodically in order to detect detects when an alarm state changes;
+
* ''ceilometer-alarm-evaluator'' avalia os alarmes periodicamente para detectar quando um estado de alarm é alterado;
* ''ceilometer-alarm-notifier'' receives notifications sent by ''ceilometer-alarm-evaluator'' when an alarm is triggered and executes the associated action
+
* ''ceilometer-alarm-notifier'' recebe notificações enviadas pelo ''ceilometer-alarm-evaluator'' quando um alarme é disparado e executa a ação associada
  
The alarm API also exposes the history of alarm state transitions and rule changes.
+
A API de alarmes também expõe o histórico de transições de estados de alarme e alterações de regras.
  
==== Collector ====
+
==== Coletor ====
* New HBase driver
+
* Novo controlador HBase
* New DB2 (NoSQL) driver
+
* Novo controlador DB2 (NoSQL)
* Improved SQLAlchemy driver
+
* Melhorado o controlador SQLAlchemy
* Improved MongoDB driver
+
* Melhorado o controlador MongoDB  
* Added a TTL functionality that allows to delete old samples from the database
+
* Adicionada uma funcionalidade TTL que permite a exclusão de amostras antigas da base de dados
* Added the ability to store events
+
* Adicionada a habilidade de armazenar eventos
* Added event storage feature on SQLAlchemy
+
* Adicionada funcionalidade de armazenamento de eventos no SQLAlchemy
  
==== Publisher drivers ====
+
==== Controladores de Publicação ====
* Added a UDP based publisher
+
* Adicionado um publicador baseado em UDP
  
==== Transformers ====
+
==== Transformadores ====
* Added new unit-scaling and rate-of-change transformers
+
* Adicionados novos transformadores de unidade escalável com taxa de mudança
  
==== Meters ====
+
==== Medidores ====
* Added a meter on API requests using a special Python middleware
+
* Adicionado um medidor nas requisições de API utilizando um middleware Python especial
* Added the ability to record samples from the new Neutron bandwidth metering feature
+
* Adicionada a habilidade de armazenar amostras para a nova funcionalidade de medição de largura de banda do Neutron
  
==== Compute agent ====
+
==== Agente de Computação ====
* Added support for Hyper-V
+
* Adicionado suporte para Hyper-V
  
=== Known Issues ===
+
=== Problemas Conhecidos ===
  
 
* https://review.openstack.org/#/c/46336/
 
* https://review.openstack.org/#/c/46336/
  
 +
== Orquestração OpenStack (Heat) ==
 +
=== Principais Novas Funcionalidades ===
  
== OpenStack Orchestration (Heat) ==
+
==== Documentação Muito Melhor ====
=== Key New Features ===
+
* [http://docs.openstack.org/developer/heat/getting_started/index.html guias inicias]
 
+
* [http://docs.openstack.org/developer/heat/ documentos de desenvolvedor]
==== Much improved documentation ====
+
* [http://docs.openstack.org/developer/heat/template_guide/index.html guia modelo]
* [http://docs.openstack.org/developer/heat/getting_started/index.html getting started guides]
+
* [http://api.openstack.org/api-ref-orchestration.html referência da API]
* [http://docs.openstack.org/developer/heat/ developer docs]
 
* [http://docs.openstack.org/developer/heat/template_guide/index.html template guide]
 
* [http://api.openstack.org/api-ref-orchestration.html API reference]
 
  
==== Initial integration with Tempest ====
+
==== Integração Inicial com Tempest ====
* API tests https://github.com/openstack/tempest/tree/master/tempest/api/orchestration
+
* Testes de API https://github.com/openstack/tempest/tree/master/tempest/api/orchestration
==== Concurrent resource operations ====
+
==== Operações de recursos concorrentes ====
* Non dependent create, update and delete operations are now performed in parallel
+
* Criação, atualização e exclusão não dependente, realizadas agora em paralelo
  
==== Much improved networking/Neutron support ====
+
==== Suporte de rede/Neutron Muito Melhor ====
* New LBaaS, FWaaS and VPNaaS resources
+
* Novos recursos LBaaS, FWaaS e VPNaaS
  
==== Initial support for native template language (HOT) ====
+
==== Suporte inicial para linguagem de modelos nativa (HOT) ====
* See [http://docs.openstack.org/developer/heat/template_guide/index.html template guide] and [http://docs.openstack.org/developer/heat/template_guide/hot_spec.html specification]
+
* Veja [http://docs.openstack.org/developer/heat/template_guide/index.html template guide] e [http://docs.openstack.org/developer/heat/template_guide/hot_spec.html especificação]
'': Note HOT is still under heavy development, and it is possible that the spec may change (we will definitely be adding to it), so please treat this as a preview and continue to use CFN template syntax if interface stability is important to you.
+
'': Note que o HOT ainda está sob desenvolvimento pesado, e é possível que a especificação mude (nós definitivamente estamos adicionando coisas), então trate isto como uma prévia e continue utilizando a sintaxe de modelos CFN se a estabilidade de interface é importante para você.
 
''
 
''
 +
==== Abstrações de Provedor e de Ambiente ====
 +
*Abstrações para fornecer uma maneira de customizar tipos de recursos utilizando modelos aninhados, veja a [http://docs.openstack.org/developer/heat/template_guide/environment.html documentação] e [http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html  o blog]
  
==== Provider and Environment abstractions ====
+
==== Integração Ceilometer para métricas/monitoramente/alarmes ====
* Abstractions to provide a way to customize resource types using nested templates see [http://docs.openstack.org/developer/heat/template_guide/environment.html documentation] and [http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html blog post]
+
*Adiciona um novo tipo de recurso [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Ceilometer::Alarm OS::Ceilometer::Alarm] que configura um alarme ceilometer
 +
* Além disto nós temos integração com alarmes do Ceilometer para ações de AutoScaling, que agora são disparadas por alarmes do Ceilometer. O mecanismo anterior onde métricas/alarmes processados pelo Heat ainda existe, mas agora é deprecado e será provavelmente removido durante a versão Icehouse.
  
==== Ceilometer integration for metrics/monitoring/alarms ====
+
==== Melhorias no UpdateStack  ====
* Adds a new resource type [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Ceilometer::Alarm OS::Ceilometer::Alarm] which configures a ceilometer alarm
 
* Also we have integration with Ceilometer alarms for AutoScaling actions, which are now triggered by Ceilometer alarms.  The previous mechanism where metrics/alarms are processed by Heat still exists, but is now deprecated and will most likely be removed during Icehouse.
 
  
==== UpdateStack improvements ====
+
* Vários tipos de recursos agora fornecem um suporte melhor para atualizações não destrutivas, incluindo o redimensionamento de uma instância. Além disto, criamos agora recursos de substituição antes de excluir o recurso anterior permitindo uma melhor continuidade de capacidade de roll-back.
  
* Several resource types now provide better support for non-destructive updates, including resizing an Instance. Also we now create replacement resources before deleting the previous resource, allowing better upgrade continuity and roll-back capability.
+
==== Integração inicial com funcionalidade de trusts do keystone ====
 +
* Integração inicial com trusts do keystone, então quando heat.conf especifica deferred_auth_method=trusts, não armazenamos mais credenciais encriptadas para realizar operações postergadas (por exemplo ajustes de AutoScaling), mas em vez disto cria um trust e armazena o ID do trust.
 +
* (Veja os problemas conhecidos abaixo)
  
==== Initial integration with keystone trusts functionality ====
+
==== Documentação de recursos melhorada ====
* Initial integration with keystone trusts, so when heat.conf specifies deferred_auth_method=trusts, we no longer store encrypted credentials to perform deferred operations (for example AutoScaling adjustments), but instead create a trust and store the ID of the trust.
+
* Geração da documentação para todos tipos de recursos http://docs.openstack.org/developer/heat/template_guide/
* (see known issues below)
+
* Schemata para recursos instalados agora estão disponíveis através da API
  
==== Improved resource documentation ====
 
* Generation of documentation for all resource types http://docs.openstack.org/developer/heat/template_guide/
 
* Schemata for installed resource types are now available through the API
 
  
==== Many more native resource types ====
+
==== Muito mais tipos de recursos nativos ====
 
* [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Cinder::VolumeAttachment OS::Cinder::VolumeAttachment]
 
* [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Cinder::VolumeAttachment OS::Cinder::VolumeAttachment]
 
* [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Firewall OS::Neutron::Firewall]
 
* [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Firewall OS::Neutron::Firewall]
Line 704: Line 649:
 
* [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server OS::Nova::Server]
 
* [http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server OS::Nova::Server]
  
==== New Rackspace resource types ====
+
==== Novos Tipos de Recursos Rackspace ====
 
* Rackspace::Cloud::DBInstance
 
* Rackspace::Cloud::DBInstance
 
* Rackspace::Cloud::LoadBalancer
 
* Rackspace::Cloud::LoadBalancer
 
* Rackspace::Cloud::Server
 
* Rackspace::Cloud::Server
  
==== Stack suspend/resume ====
+
==== Suspender/resumir stack  ====
* Support for a new API "actions" path, which enables stack suspend/resume
+
* Suporte para um novo caminho de "ações" de API, que habilita suspender/resumir o stack
  
==== Consolidated configuration to a single heat.conf and a single paste-api.ini ====
+
==== Configuração consolidada para um único heat.conf e paste-api.ini ====
* See upgrade notes below
+
* Veja notas de atualização abaixo
* Also added new config options to provide limitations on:
+
* Também adicionadas novas configurações de opções que fornecem limitações de
: template size
+
: tamanho de modelo
: number of stacks per tenant
+
: número de stacks por tenant
: number of events per stack
+
: número de eventos por stack
: stack nesting depth
+
: profundidade de aninhamento de stack
  
==== Heat Standalone Mode ====
+
==== Modo Heat Standalone ====
* Heat can now be configured to run in standalone mode, allowing it to orchestrate onto an external OpenStack
+
* Heat agora pode ser configurado para rodar em modo standalone, permitindo ele orquestrar um OpenStack externo
  
==== Known Issues ====
+
==== Problemas Conhecidos ====
* Heat does not support specifying region name when getting API endpoints from keystone see [https://bugs.launchpad.net/python-keystoneclient/+bug/1147530 bug]
+
* heat não suporta espeficar o nome de região quando busca os endpoints de API do keystone, veja [https://bugs.launchpad.net/python-keystoneclient/+bug/1147530 bug]
* Integration with keystone trusts (deferred_auth_method=trusts) will only work if you have the latest keystoneclient 0.4.1, however this is not reflected in the requirements.txt of Heat yet
+
* Integração com keystone trusts (deferred_auth_method=trusts) irá funcionar apenas com o último keystoneclient 0.4.1, entretanto isto não está refletido ainda no requirements.txt do Heat
 
: https://bugs.launchpad.net/python-keystoneclient/+bug/1231483
 
: https://bugs.launchpad.net/python-keystoneclient/+bug/1231483
* Integration with keystone trusts requires at least RC3 of keystone due to this issue
+
* Integração com trusts de keystone requer ao menos o RC3 do keystone devido à este problema
 
: https://bugs.launchpad.net/keystone/+bug/1239303
 
: https://bugs.launchpad.net/keystone/+bug/1239303
  
==== Upgrade Notes ====
+
==== Notas de Atualização ====
* Heat now uses one config file (/etc/heat/heat.conf) instead of per-service files.
+
* Heat utiliza agora um arquivo de configuração (/etc/heat/heat.conf) em vez de um arquivo por serviço.
* The API processes now use a single paste configuration file (/etc/heat/api-paste.ini) instead of per-service files.
+
* Os processos de API utilizam agora uma única configuração de paste (/etc/heat/api-paste.ini) em vez de um arquivo por serviço.
* There is now support for a global environment definition in /etc/heat/environment.d/ (see [http://docs.openstack.org/developer/heat/template_guide/environment.html environment documentation])
+
* Existe agora suporte para uma definição de ambiente global em /etc/heat/environment.d/ (veja [http://docs.openstack.org/developer/heat/template_guide/environment.html environment documentation])
* All OS::Neutron* resources have been renamed "OS::Quantum*", the old names will still work if you install the provided default environment which aliases the old names to the new resources.
+
* Todos recursos OS::Neutron* foram renomeados para "OS::Quantum*", os nomes antigos ainda irão funcionar se você instalar o ambiente padrão fornecido que cria apelidos dos  nomes antigos para os novos recursos.
  
 
== Documentação do OpenStack ==
 
== Documentação do OpenStack ==

Latest revision as of 11:12, 29 October 2013

Contents

Notas de lançamento do OpenStack 2013.2 (Havana)

Neste documento você irá encontrar uma descrição das principais novas funcionalidades, bugs conhecidos e dicas de atualização para a versão 2013.2 (Havana) do OpenStack.


Armazenamento de Objetos OpenStack (Swift)

Principais novas funcionalidades

  • Suporte à Clusters Globais

O conceito de "região" introduzido no Swift 1.8.0 foi aumentado com suporte ao uso de uma rede de replicação separada e configuração de afinidade de leitura e escrita. Estas funcionalidades combinadas oferecem suporte à um único cluster Swift abrangendo uma grande área geográfica.

  • Adicionado suporte ao arquivo de configuração conf.d

Permite aos daemons e servidores Swift aceitarem opcionalmente um diretório como parâmetro de configuração. Isto permite que diferentes partes do arquivo de configuração sejam gerenciadas separadamente, ex: o middleware poderia utilizar um arquivo de configuração separado para suas configurações em particular.

  • Performance de Disco

O servidor de objetos agora pode ser configurado para utilizar um pool de threads para aumentar a performance e suavizar a latência por todo o sistema. Além disto, muitas operações de disco foram reordenadas para aumentar a confiabilidade e melhorar a performance.

  • Adicionado suporte para pooling de conexões memcache.
  • Cálculos muito mais rápidos para escolher os nodos de handoff.

Correção de bugs significativos

  • Corrigido bug onde as entradas memcache não expiravam
  • Corridigo problema onde o proxy continuaria lendo de um servidor de armazenamento mesmo após o cliente desconectar.
  • Corrigido problema com manipulação de UTF-8 em escritas versionadas.

Polimentos operacionais adicionais

  • Define o número de workers wsgi padrão para cpu_count

Alterado o valor padrão de workers wsgi de 1 para auto. O novo valor padrão para workers no proxy, contêiner, conta e servidores de objetos wsgi irá gerar tantos workers por processo quanto houver núcleos de CPU. Isto não será o ideal para algumas configurações, mas é muito mais provável de dar certo na implantação inicial.

  • Adicionado ajuste de configuração reveal_sensitive_prefix para filtrar o token de autenticação logado pelo servidor proxy.
  • Adicionado suporte à replicação de partições de handoff primeiro na replicação de objetos. Também pode-se configurar agora com quantos nodos remotos um nodo de armazenamento deve falar antes de remover uma partição local de handoff.
  • Numerosas melhorias para fazer o Swift funcionar com PyPy.

Problemas Conhecidos

Notas de Atualização

Leia o log de alterações completo em https://github.com/openstack/swift/blob/master/CHANGELOG para verificar alguma alteração de configuração que possa afetar atualizações.

Como sempre, Swift pode ser atualizado sem perda de disponibilidade.

OpenStack Compute (Nova)

Principais Novas Funcionalidades

API

  • A API REST de Computação (Nova) inclui uma nova versão experimental (v3). A nova versão da API inclui uma boa limpeza, bem como um framework para implementar e versionar extensões de API. Espera-se que esta API seja finalizada na versão Icehouse (blueprint).
  • Estas extensões da API REST de Computação (Nova) foram adicionadas:
    • CellCapacities: Adiciona a habilidade de determinar a quantidade de RAM em uma Célula, e a quantidade de RAM que está livre em uma Célula (blueprint).
    • ExtendedFloatingIps: Adiciona o parâmetro opcional fixed_addressao comando de IP flutuante, permitindo que um IP flutuante seja associado à um IP fixo (blueprint).
    • ExtendedIpsMac: Adiciona endereços MAC à resposta do servidor (blueprint).
    • ExtendedQuotas: Adiciona a habilidade para administradores excluírem uma cota não-padrão de um tenant, revertendo ele para a cota padrão (blueprint).
    • ExtendedServices: Adiciona a habilidade de armazenar e exibir o motivo pelo qual um serviço foi desabilitado (blueprint).
    • ExtendedVolumes: Adiciona na informação de instância os volumes anexados (blueprint).
    • Migrations: Adiciona a habilidade de listar operações de redimensionamento e migração em progresso pela Célula ou Região (blueprint).
    • ServerUsage': Adiciona os valores launched_at e terminated_at na resposta do instance show (blueprint).
    • UsedLimitsForAdmin: Permite a recuperação de limites de cota específicos de tenants via API administrativa

(blueprint).

  • A API EC2 do serviço de Computação foi atualizada para utilizar os códigos de erro que são mais consistente com os da API oficial EC2

(blueprint).

Células

  • O Agendador de Células foi atualizado para suportar filtragem e pesos via as novas opções scheduler_filter_classes' e scheduler_weight_classes no grupo de configuração de [células]. Os novos módulos de peso ram_by_instance_type e weight_offset também foram adicionados, removendo a seleção aleatória de Células utilizada nas versões anteriores. isto torna o trabalho de agendamento de células conceitualmente similar ao agendamento de hosts existente (blueprint).
  • Migração viva de instâncias de máquina virtual é agora suportada dentro de uma única célula. Migração viva de instâncias de máquina virtual entre Células não é suportada (blueprint).
  • Cinder é agora suportada pelo Nova quando utilizando Células (blueprint).

Computação

Geral
  • Adicionado suporte de Hipervisor para contêineres criados e gerenciados utilizando Docker (blueprint).
  • Nova possui uma nova funcionalidade que permite "colocar na prateleira" uma instância. Isto permite que instâncias que estão paradas por um período estendido sejam movidas para fora do hipervisor para liberar recursos (blueprint).
  • A seção vendor_data foi adicionada ao serviço de metadados e funções de configuração. Isto permite a extensão dos metadados disponíveis aos convidados para incluir dados específicos de vendor ou de local (blueprint).
Controlador Baremetal
  • Adicionado um backend suportando provisionamento bare-metal Tilera ao driver de Baremetal (blueprint).
Controlador Hyper-V
  • Suporte ao WIndows Server / Hyper-V Server 2012 R2 (blueprint).
  • Suporte à armazenamento efêmero (blueprint).
  • Suporte ao Ceilometer para integração de métricas de computação (blueprint).
Controlador libvirt (KVM)
  • Suporte ao agente de convidado QEMU (qemu-guest-agent) foi adicionado para os convidados criados com a a propriedade de hw_qemu_guest_agent definida como "yes" (blueprint).
  • Suporte para passagem direta de dispositivos PCI do nodo de computação para os convidados virtualizados foi adicionado ao Nova. Atualmente apenas o driver libvirt fornece uma implementação funcional (blueprint base, libvirt blueprint).
  • Adicionado suporte para extração de parâmetros de QoS do Cinder e limitação de acesso ao disco baseado neles quando utilizando hipervisores baseados em libvirt (blueprint).
  • RBD é agora suportado como um backend para armazenamento de imagens (blueprint).
Controlador PowerVM
  • Adicionado suporte à reinicialização hard (alteração).
Controlador vmwareapi (VMWare)
  • Suporte ao gerenciamento de múltiplos clusters (blueprint).
  • Estratégia de clonagem de imagem que as imagens especifiquem se devem ser utilizadas como um clone linkado ou imagens de clone completas (blueprint)
  • Suporte para o uso de um controlador de configuração (blueprint).
Controlador XenServer
  • Suporta a exibição do log de um console de servidor (blueprint)
  • Suporta a divisão de discos efêmeros grandes em pedaços de 1024GB ou 2000GB para contornar as limitações de tamanho máximo VHD (blueprint)
  • Permite que as imagens possuam o ajuste AutoDiskConfig=disabled para significar que os usuários não podem setar AutoDiskConfig=Manual nestas imagens e servidores (blueprint).
  • Melhorias em como o Nova comunica-se com o agente Nova, para que você possa utilizar tanto o agente cloud-init e Nova na mesma nuvem (blueprint).
  • Habilidade de iniciar VMs em um estado onde eles elas estão rodando o instalador de uma distribuição Linux, para auxiliar usuários à construir suas próprias imagens customizadas (blueprint).
  • Suporte experimental para XenServer core, e rodar nova-compute em um XenServer core Dom0 (blueprint).
  • Suporte experimental para o uso de armazenamento SR LVHD, e suporte para iniciar de imagens glance raw comprimidas (blueprint).
  • Muito trabalho para melhorar a estabilidade e suportabilidade. Exemplos incluem a habilidade de configurar a taxa de compressão utilizada por snapshots enviados ao glance e rollback automático de erros durante o redimensionamento de servidores devido aos discos serem muito pequenos para o tamanho destinho.

Cota

  • A cota padrão agora é editável, anteriormente o valor desta cota era fixo. Utilize o comando nova quota-class-update default <chave> <valor> para atualizar a cota padrão (blueprint).
  • Cotas podem agora ser definidas por usuário (blueprint).
  • Cotas para um dado tenant ou usuário agora podem ser excluídas e suas cotas retornarão ao padrão (blueprint).

Redes

  • Alocação de Rede e endereço IP é realizada agora em paralelo com outras operações envolvidas no provisionamento de uma instância, resultando em tempos de inicialização menores (blueprint).
  • Nova agora passa o nome do host do nodo de Computação selecionado para hospedar uma instância para o Neutron. Plug-ins do Neutron podem agora utilizar esta informação para alterar a configuração de rede física do nodo de Computação conforme requerido (blueprint).

Notificações

  • Notificações agora são geradas quando os agregados de host são criados, excluídos, expandidos, contraídos ou de outra maneira atualizados (blueprint).

host-aggregate blueprint]).

  • Notificações agora são geradas quando a construção de uma instância falha (blueprint).

Agendador

  • Adicionado force_nodes para filtrar propriedades, permitindo aos operadores explicitamente especificar o nodo para provisionamento quando utilizando o driver baremetal (blueprint).
  • Adicionada a habilidade de tornar o IsolatedHostsFilter menos restritivo, permitindo que hosts isolados utilizem todas as imagens manipulando o valor da nova diretiva de configuração restrict_isolated_hosts_to_isolated_images no nova.conf (blueprint).
  • Adicionado GroupAffinityFilter como contrapartida ao existente GroupAntiAffinityFilter. O novo filtro permite o agendamento de uma instância em um host de um grupo específico de hosts (blueprint).
  • Adicionada a habilidade para que filtros definam o novo parâmetro run_filter_once_per_request para True se espera-se que suas decisões de filtragem permaneçam válidas para todas instâncias em uma requisição. Isto previne o filtro de ter que ser re-executado para cada instância na requisição quando isto não é necessário. Este ajuste foi aplicado em inúmeros filtros existentes (blueprint).
  • Adicionados filtros por agregado AggregateRamFilter e AggregateCoreFilter os quais se aplicam em agregados de host em vez de globalmente. AggregateDiskFilter será adicionado em uma versão futura (blueprint).
  • A performance do agendador foi melhorada pela remoção de mensagens periódicas que eram transmitodas de todos nodos de computação para todos agendadores (blueprint).
  • A performance do agendador foi melhorada permitindo que os filtros especifiquem que eles precisam rodar apenas uma vez para uma dada requisição para múltiplas instâncias (blueprint).

Armazenamento

  • Volumes Cinder anexados agora podem ser encriptados. Os dados são decriptados conforme a necessidade na leitura e escrita enquanto apresenta instâncias com um dispositivo de armazenamento de blocos normal (blueprint).
  • Adicionada a habilidade de transparentemente trocar o volume Cinder anexado à uma instância. Apesar de a instância poder parar brevemente enquanto o volume é trocado nehuma leitura ou escrita é perdida (blueprint).
  • Quando conectando em volumes apoiados por NFS ou GlusterFS Nova agora utiliza as opções de montagem definidas na configuração do Cinder. Anteriormente as opções de montagem precisavam ser definidas em cada nodo de computação que iria acessar os volumes (blueprint).
  • Adicionado suporte nativo ao GlusterFS. Se qemu_allowed_storage_drivers está definido para gluster no nova.conf então QEMU está configurado para acessar o volume diretamente utilizando libgfapi em vez de através do fuse (blueprint).
  • Snapshots auxiliados pelo QEMU agora são utilizados para fornecer a habilidade de criar snapshots de volumes Cinder, mesmo quando o armazenamento em uso não suporta eles nativamente, como o GlusterFS (blueprint).
  • O protocolo de transporte iSER é agora suportado para acessar o armazenamento, fornecendo melhorias de performance comparada ao uso de iSCSI sobre TCP (blueprint).

Conductor

  • O Conductor agora é capaz de gerar múltiplas threads worker operando em paralelo, o número de threads a serem geradas é determinado pelo valor de workers em nova.conf (blueprint).

Alterações Internas

  • Nova agora utiliza a infraestrutura comum de serviços fornecida pelo Oslo (blueprint).
  • Alterações foram realizadas que irão permitir a o backport de correções de bugs que requerem a migração da base de dados (blueprint).
  • Uma quantidade significante de progresso foi feita em direção ao suporte de upgrades vivos de uma implantação Nova. Na Havana, melhorias incluem controles adicionais sobre as versões das mensagens enviadas entre os serviços (veja a seção [upgrade_levels] no nova.conf)

(blueprint), e uma nova camada de objetos que ajuda a desacoplar o código base dos detalhes do esquema da base de dados (blueprint).

Problemas Conhecidos

  • Se você está utilizando células, existe um problema ao se excluir instâncias. Diferentemente do Grizzly, excluir instâncias irá excluí-las imediatamente da celúla de mais alto nível (API) antes de informar a célula filha para excluir a instãncia. Isto não era esperado. Um efeito colateral disto é que notificações delete.start e delete.end serão enviadas. Se a exclusão da instância na célula filha for bem sucedida, uma segunda notificação delete.start e delete.end será enviada. Se não for, os BDs ficarão fora de sincronia quando a instância parece ter saído da célula da API, mas ainda existe na célula filha. O código natural de cura construído nas células irá acabar corrigindo isto e restaurando a instância no DB da célula de API após algum tempo, dependendo da configuração de cura. Este bug será corrigido em havana-stable em pouco tempo após o lançamento.
  • Verifique http://bugs.launchpad.net/nova

Notas de Atualização

  • Note que as tarefas periódicas agora irão rodar mais frequente que antes. A frequência com que as tarefas periódicas rodar sempre foi configurável, entretanto o timer para quando rodar a tarefa de novo era iniciado previamente após a última execução em que a tarefa completou. Agora as tarefas rodam em uma frequência constante, independente da duração da execução. Isto deixa muito mais claro quando as tarefas supostamente devem rodar. Entretanto o efeito colateral é que as tarefas agora irão rodar um pouco mais seguido por padrão (https://review.openstack.org/#/c/26448/).
  • A opção security_groups_handler foi removida do nova.conf. Ela foi adicionada por causa do Quantum e não é mais necessária (https://review.openstack.org/#/c/28384/).
  • Esta mudança não deve afetar atualizações, mas é uma mudança no comportamente para todas novas implantações. Versões anteriores criavam o flavor padrão m1.tiny com um tamanho de disco 0. O valor padrão agora é 1. 0 significa não realizar nenhum redimensionamento de disco e usar o tamanho de disco que estiver na imagem. 1 significa impor um limite de 1GB. O valor especial 0 ainda é suportado se você desejar criar ou modificar flavors para utilizá-lo (https://review.openstack.org/#/c/27991/).
  • Um framework de plugins foi removido já que o que era fornecido era possível através de outros meios (https://review.openstack.org/#/c/33595).
  • A opção de configuração notify_on_any_change foi removida (https://review.openstack.org/#/c/35264/).
  • A opção compute_api_class foi deprecada e será removida em uma versão futura (https://review.openstack.org/#/c/28750/).
  • Nova agora utilizar Neutron após Quantum ser renomeado (https://review.openstack.org/#/c/35425/).
  • Nova irá agora rejeitar requisições para criar um servidor quando existem múltiplas redes Neutron definidas, mas nenhuma rede especificada na requisição de criação de servidor. Nova anteriormente anexava o servidor à *todas* redes, mas o consenso era que o comportamento não fazia sentido (https://review.openstack.org/#/c/33996/).
  • A configuração vmware da variável 'vnc_password' está agora deprecada. Um usuário não precisa mais de uma senha para ter acesso VNC. Isto agora funciona como todos outros controladores de virtualização (https://review.openstack.org/#/c/43268/).

Serviço de Imagem do OpenStack (Glance)

Principais novas funcionalidades

Proteções de propriedade

Grupos específicos de usuários agora podem ser autorizados a criar, atualizar, e ler diferentes propriedades de entidades arbitrárias. Existem dois tipos de propriedeades no Serviço de Imagem:

  • Propriedades núcleo, como especificado pelo esquema da imagem.
  • Meta propriedades, as quais são pares arbitrários de chave/valor que podem ser adicionados em uma imagem.

Acesso às meta propriedades através de chamadas da API pública do Serviço de Imagem agora podem ser restritas à certos conjuntos de usuários, utilizando um arquivo de configuração de proteções de propriedades (especificado no arquivo glance-api.conf). Por exemplo:

  • Limitar todas interações de propriedade somente para administradores.
  • Permitir ambos administradores e usuários com o papel de cobrança, ler e modificar todas propriedades prefixadas com ``x_billing_code_``.

blueprint

API de Registro

Uma nova API foi criada para o serviço de Registro (compatível com db_api) utilizando RPC sobre HTTP. A API:

  • Permite que o Glance continue à suportar implantações legadas que estavam utilizando o serviço de registro anterior. Glance v2 abandonou completamente o uso de um serviço de registro o qual em alguns casos poderia resultar em uma vulnerabilidade de segurança (todos parâmetros da base de dados precisavam estar presentes no glance-api.conf se implantado como um serviço 'público')
  • Torna mais fácil implementar novos métodos para a API da base de dados sem ter que modificar a API do registro.

blueprint

Atualizações incluem um driver de base de dados de registro que fala com um serviço de registro remoto, que por sua vez fala diretamente com o back end da base de dados. O serviço de registro implementa todas funções públicas da API da base de dados que são utilizadas fora da API. A API v2 do Serviço de Imagem deve estar habilitada, e o cliente do Serviço de Imagem deve apontar para ela. blueprint

Suporte de Armazenamento

O Serviço de Imagem agora suporta o seguinte para armazenamento de back-end:

  • Sheepdog. O Serviço de Imagem agora pode armazenar imagens em um cluster de back-end Sheepdog. Sheepdog é um projeto open-source, que oferece um armazenamento distribuído para QEMU.

"Website do Sheepdog" blueprint

  • Cinder. Agora o Cinder do OpenStack pode ser utilizado como um backend de armazenamento de bloco para o Serviço de Imagem. blueprint
  • GridFS. O Serviço de Imagem suporta agora o sistema de arquivos distribuído GridFS. O suporte é habilitado utilizando as novas opções do .conf mongodb_store_uri e mongodb_store_db. Localidades GridFS na forma `gridfs://<IMAGE>` são suportadas. "GridFS Website" blueprint

Localização de Imagens Múltiplas

Imagens do Serviço de Imagem agora podem ser armazenadas em múltiplos locais. Isto permite o consumo eficiente dos dados de imagem e o uso de imagens de backup em caso de falha de uma imagem primária. blueprint

Atualizações relacionadas incluem:

  • Uma camada de políticas para APIs de localização, para permitir verificações de políticas para trocar a localização das imagens. blueprint
  • Metados de URL diretos. Cada sistema de armazenamento do Serviço de Imagens pode armazenar agora os metadados de localização na base de dados de localização de imagem, permitindo que ele retorne os metadados específicos de URL para o cliente quando direct_url está habilitado. Por exemplo, dado um arquivo://URL, o host de exportação NFS, o ponto de montagem e o tipo de sistema de arquivos podem agora ser retornados para o cliente. blueprint
  • Suporte à múltiplas localidades ao baixar imagens. Isto permite que os clientes da API consumam imagens de múltiplos armazenamentos de backend. blueprint
  • Checksum de propriedade de imagem indexado. A propriedades de imagem checksum agora é indexada permitindo aos usuários buscar por uma imagem especificando o checksum. blueprint
  • Atualização do Scrubber. O Scrubber é um utilitário que limpa imagens que foram excluídas. O scrubber agora suporta múltiplas localidades para imagens 'pending_delete'. blueprint
  • Verificação de metadados. Agora pode ser habilitado a verificação de metadados na camada do proxy quando a localização muda. blueprint

Mas espere, tem mais!

  • Contêineres e formatos de disco configuráveis. Anteriormente o Glance suportava apenas um conjunto específico de contêineres e formatos de disco, os quais eram raramente o conjunto de formatos realmente suportados por uma implantação. O conjunto de contêineres e formatos de disco agora pode ser configurado blueprint
  • Cota de Armazenamento. Usuários agora podem ser limitados à N bytes (soma total) através de todos sistemas de armazenamento (total_storage_quota configurado em .conf file). blueprint
  • Política de Membros. Reforço de Políticas foi adicionado nas APIs de membros (similar à política de reforço de imagem/localização). Novas políticas incluem 'new_member', 'add_member', 'get_member', 'modify_member', 'get_members', e 'delete_member'. blueprint

Notas de Atualização

  • Opção para pular autenticação no registro do Glance. Se o implantandor tem uma conexão segura entre o servidor de API Glance e o servidor de Registro Glance, você pode agora como uma otimização de performance pular a reautenticação do servidor de Registro. Selecione uma pipeline glance-registry-trusted-auth na configuração de registro, e defina o valor de configuração 'send_identity_headers' para True na configuração da API. Então a API Glance envia os cabeçalhos de identidade requeridos como informação de usuário e tenant para o registro glance. Tenha em mente o custo de segurança se você adotar esta configuração.
  • Opção de Compressão SSL do Armazenamento Swift. O valor de configuração 'swift_store_ssl_compression' torna possível desabilitar a camada de compressão SSL das requisições swift HTTP. Isto pode melhorar a performance para imagens que já estão em um formato comprimido.

Problemas Conhecidos

OpenStack Dashboard (Horizon)

Visão Geral da Versão

O ciclo de lançamento da versão Havana traz suporte para *três* novos projetos, mais significantes novas funcionalidades para vários projetos existentes. Em cima de tudo isto, muitos aspectos da experiência de usuário foram melhorados tanto para usuários quanto para administradores. A comunidade continua crescendo e expandindo. A versão Havana é a mais sólida e melhor versão do projeto OpenStack Dashboard até agora!

Destaques

Novas Funcionalidades

Heat

O projeto de Orquestração do OpenStack (Heat) estreou no Havana, e Horizon entrega suporte completo para o gerenciamento de seus stack Heat. Destaques incluem o suporte para a geração de formulários dinâmicos á partir de formatos de modelos do Heat, visualização de topologia de stack, e inspeção completa de recursos de stack.

Ceilometer

Também estreando na Havana está o projeto de medições OpenStack (Ceilometer). Suporte inicial para o Ceilometer está incluído no Horizon para que seja possível que um administrador consulte a utilização da nuvem através do Dashboard e compreender melhor como o sistema está funcionando e sendo utilizado.

Domínios, Grupos, e mais: Suporte à API de Identidade v3

Com a API v3 dos serviços de Identidade do OpenStack (Keystone) completamente desenvolvida na versão Havana, Horizon adicionou suporte completo para todas as novas funcionalidades como Domínios e Gruopos, Gerenciamento de papéis e atribuição para Domínios e Grupos, autenticação baseada em Domínios, e Troca de contexto de domínio.

Bases de Dados Trove

O projeto Bases de dados como um serviço do OpenStack graduou-se da incubação no ciclo Havana, e graças à sua determinação eles entregaram um conjunto de painéis para o OpenStack dashboard para permitir o provisionamento e gerenciamento de suas bases de dados do Trove e backups. Declaração: Dado que a primeira versão oficial do Trove como um projeto integrado não será antes de IceHouse, esta funcionalidade deve ser considerada experimental e sujeita a mudanças.

Funcionalidades Nova

O número de funcionalidades do OpenStack Compute (Nova) suportadas no Horizon continuam à crescer. Novas funcionalidades no ciclo Havana incluem:

  • Cotas padrão editáveis.
  • Habilidade para um administrador resetar a senha de um servidor/instância.
  • Suporte à Zonas de disponibilidade.
  • Suporte à regiões melhorado.
  • Redimensionamento de instâncias.
  • Suporte ao boot de volume melhorado.
  • Suporte à flavors por projeto.

Todos estes fornecem um conjunto mais rico de opções para controlar onde, quando e como as instâncias são disparadas, e melhora como elas são gerenciadas uma vez que estão rodando.

Funcionalidades Neutron

Um número de novas funcionalidades do OpenStack Networking (Neutron) são exibidas na versão havana, mais notavelmente:

  • VPN como um serviço.
  • Firewall como um serviço.
  • Visualização de topologia de rede editável e interativa.
  • Paridade completa de grupos de segurança e cotas entre Neutron e Nova Network.

Estas funcionalidades permite uma tremenda flexibilidade quando se for construir redes definidas em sofware para sua nuvem utilizando Neutron.

Melhorias de Experiência de Usuário

Troca de senha self-service

Apoiado por mudanças na API de Identidade v2.0 (Keystone), usuários agora podem modificar suas próprias senhas sem a necessidades de envolver um administrador. Isto é mais seguro e menos trabalhoso para todos. Esta funcionalidade ainda não está disponível para usuários da API v3 de Identidade.

Melhor Arquitetura de Informação de Administração

Várias seções do dashboard de administração foram rearranjadas para agrupar mais logicamente a informação. Além disto, novas fontes de informação foram aducionadas permitindo aos administradores compreender melhor o estado dos hosts na nuvem e seu relacionamento com os agregados de host, zonas de disponibilidade, etc.

Melhoria nas mensagens aos usuários no Logout

Vários novos indicadores foram adicionados para informar os usuários porque eles fora deslogados quando acabam na tela de login inesperadamente. Estes indicadores deixam claro se a sessão do usuário expirou, o tempo esgotou por inatividade, ou eles não estão autorizados para a seção do dashboard que tentaram acessar.

Modelos de Regras de Grupos de Segurança

Já que existem muitas regras de grupos de segurança bastante comuns que os usuários necessitam tediosamente readicionar cada vez (regras para SSH e ping, por exemplo) o time do Horizon adicionou modelos pré-configurados para regras comuns que um usuário pode selecionar e adicionar ao seu grupo de segurança com dois cliques. Estas regras são configuráveis através das definições SECURITY_GROUP_RULES.

Comunidade

Time de Tradução

As traduções do OpenStack vieram com tudo neste ciclo Havana e a qualidade das traduções no Horizon são as melhores até agora, de longe. Parabéns ao time por seu sucesso em construir a comunidade que começou primariamente dentro do projeto OpenStack Dashboard.

Grupo de Experiência de Usuário

Um novo grupo de Experiência de Usuário do OpenStack se formou durante o ciclo Havana com a missão de melhor a UX por todo o OpenStack. Eles rapidamente se tornaram indispensáveis no processo de projetar e melhorar funcionalidades no OpenStack Dashboard. Espere melhoria futura significante na Experiência de Usuário agora que existem pessoas dedicadas ativamente colaborando para aumentar o patamar.

Embaixo do capô

Compilação LESS menos complicada: Sem NodeJS

Devido à solicitações de várias partes, e possível por melhorias no suporte da comunidade Python ao LESS, Horizon removeu todos os traços de NodeJS do projeto. Agora nõs utilizamos o módulo lesscpy para compilar nosso LESS na página de estilos final. Isto não deve afetar a maioria dos usuários de maneira alguma, mas facilita a vida para distribuições downstream similares.

Controle de Acesso Baseado em Papéis

Horizon começou a transição para o uso dos arquivos policy.json de outros projetos do OpenStack para reforçar o controle de acesso no dashboard se os arquivos forem fornecidos. Isto significa que os controles de acesso são mais configuráveis e podem ser mantidos em sincronia entre o projeto original e Horizon. Atualmente isto só é suportado para o Keystone e partes dos arquivos de políticas do Nova. Suporte total virá na próxima versão. Você irá precisar setar as definições de POLICY_FILES_PATH e POLICY_FILES para habilitar esta funcionalidade.

Outras Melhorias e Correções

  • Contêiner Swift e metadados de objetos são agora suportados.
  • Novas visualizações para utilização e cotas.
  • As funcionalidade adicionais do plugin do Roteador Cisco N1K estão disponíveis através de um dashboard adicional especial quando habilitado e suportado no Neutron.
  • Suporte para verificação de certificados SSL auto-assinados ou outros especificados.
  • Tipos de imagens Glance agora são configuráveis.
  • Ordenação foi melhorada em muitos locais através do dasboard.
  • Otimizações na eficência de chamadas de API.
  • Campos requeridos em formulários agora são melhor indicados.
  • Tempo limite de sessão agora pode ser habilitado para deslogar o usuário após um período de inatividade para maior segurança.
  • Melhorias significantes de concordância PEP8 e de qualidade de código.
  • Centenas de correções de bugs e melhorias menores de experiência de usuário.

Informação de Atualização

Hosts Permitidos

Para implantação em produção do Horizon você deve adicionar a definição ALLOWED_HOSTS no seu arquivo settings.py ou local_settings.py. Esta definição foi adicionada no Django 1.5 e é uma funcionalidade de segurança importante. Para mais informação sobre isto por favor consulte o arquivo de exemplo local_settings.example.py ou a documentação do Django.

Habilitando Funcionalidades Keystone e Neutron

Se você possui configurações existentes para a definição OPENSTACK_KEYSTONE_BACKEND ou OPENSTACK_NEUTRON_NETWORK, você vai querer consultar o arquivo local_settings.example.py por informações das novas opções que foram adicionadas. Configurações existentes continuarão funcionando, mas não terão as chaves corretas para habilitar algumas das novas funcionalidades do Havana.

Problemas Conhecidos e Limitações

Criação de Sessão e Verificação de saúde

Se você utiliza um serviço de monitoramento de saúde que pinga a página inicial combinado com um backend de sessão apoiado por uma base de dados, você pode encontrar criação de sessões excessivas. Este problema está relacionado para ser corrigido em breve, mas neste meio tempo a solução recomentada é escrever um job periódico que exclui as sessões expiradas do seu armazenamento de sessões regularmente.

Excluir um grande número de recursos simultâneamente

Utilizar a caixa "selecionar tudo" para excluir um grande número de recursos de uma única vez pode atingir o tempo limite de rede (dependendo da configuração). Isto deve-se às APIs por baixa não suportarem a exclusão em lote nativamente, e consequentemente o Horizon precisa enviar requisições de exclusão para cada recurso indivudualmente nos bastidores.

Nomes de Grupos de Segurança Conflitantes com Neutron

Sempre onde Nova Network utiliza apenas o nome de um grupo de segurança quando especifica grupos de segurança no momento de disparar uma instância, Neutron pode aceitar tanto um nome quanto UUDI. Para suportar ambos , o Horizon passa o nome do grupo de segurança selecionado. Entratanto, devido à alguns problemas de isolamento de dados no Neutron existe um problema que pode surgir se um usuário administrador tentar especificar um grupo de segurança com o mesmo nome de outro grupo de segurança em um projeto que ele também possui acesso. Neutron irá encontrar múltiplas ocorrências para o grupo de segurança e irá falhar ao disparar a instância. A maneira de contornar isto é tratar os nomes de grupos de segurança como únicos para todos usuários administradores.

Gráficos quebrados para recursos não computacionais

Os gráficos de linha da página de utilização de recursos não exibe recursos não computacionais quando se escolhe agrupar por -- https://bugs.launchpad.net/horizon/+bug/1243796

Retrocompatibilidade

A versão Horizon Havana deve ser totalmente compatível tanto com Havana quanto com Grizzly do restante dos projetos integrados do OpenStack (Nova, Swift, etc.) Novas funcionalidades em outros projetos OpenStack qe não existiam em Grizzly irão obviamente funcionar no Horizon apenas se o resto da pilha suportar elas também.

Em geral, um grande esforço foi realizado para manter compatibilidade para desenvolvedores terceiros que construíram sobre o Horizon até agora.

Identidade OpenStack (Keystone)

Principais Novas Funcionalidades

  • Flexibilidade de implantação melhorada.
    • Dados de autorização (tenants/projetos, papéis, atribuição de papéis; ex: SQL) agora podem ser armazenadas em um backend separado, como determinado pelo controlador de "atribuições", a partir dos dados de autenticação (usuários, grupos; ex: LDAP), como determinado pelo controlador de "identidade".
    • Credenciais (ex: tokens EC2) agora podem ser armazenados em um backend separado conforme determinado pelo controlador de "credenciais", a partir dos dados de autenticação.
    • Habilidade de especificar políticas RBAC mais granulares (por exemplo, basedas em atributos da requisição / corpo de resposta da API).
    • Manipulação plugável de autenticação externa utilizando REMOTE_USER.
    • Geração de token, que atualmente é baseada em UUID ou PKI, é agora plugável e separada da persistância de token. Implantadores podem escrever uma implementação customizada da interface keystone.token.provider.Provider e configurar o keystone para utilizar ele com [token] provider. Como resultado, [signing] token_format é agora deprecado em favor desta nova opção de configuração.
    • Suporte de primeira classe para a implantação atrás de Apache httpd.
  • Novas funcionalidades de implantação.
    • Habilidade de armazenar em cache os resultados de chamadas de controlador em um armazenamento chave-valor (por exemplo memcached ou redis).
    • Comando keystone-manage token_flush para ajudar a limplar tokens expirados.
  • Novas funcionalidade de API.
    • Autorização delegada baseada em papéis para consumidores arbitrários utilizando OAUTH 1.0a.
    • Clientes de API agora pode escolher remover o catálogo de serviços incluído em uma resposta de token.
    • Atribuição de papéis de domínio podem agora ser herdadas pelo domínio do projeto.
    • API de atribuição de papéis agregados.
    • Provedores de autenticação externa agora podem embutar uma referência de ligação nos tokens para que serviços remotos possam opcionalmente validar a identidade do usuário apresentando o token contra um mecanismo de autenticação externo. Atualmente, apenas kerberos é suportado.
    • Endpoints agora podem ser explicitamente mapeados para projetos, efetivamente prevenindo certos endpoints de aparecerem no catálogo de serviços baseado no escopo do token do projeto. Isto não previne usuários de acessar ou utilizar endpoints que eles conhecem através de outros meios.
  • Notificações de eventos emitidas para operações de criação, atualização e exclusão de usuários e projeto/tenant
  • Melhorias gerais de performance
  • A API v2 e v3 agora utilizam a mesma lógica para computar a lista de papéis atribuídos a um par usuário-projeto durante a autenticação, baseado nas atribuições de papéis usuário+projeto, grupo+projeto, usuário+herança de domínio, e grupo+herança de domínio (onde atribuições de papel por herança de domínio permite uma atribuição de papéis em nível de domínio para aplicar em todos projetos do domínio). A API v3 agora utiliza uma abordagem similiar para computar as atribuições de papel para token de escopo de domínio.
  • Logs são manipulados utilizando uma implementação comum de logging do incubador Oslo, consistente com outros projetos do OpenStack.
  • Migrações de SQL para extensões podem agora ser gerenciadas independentemente do repositório de migração primária utilizando keystone-manage db_sync --extension=«extension-name».

Problemas Conhecidos

  • six v1.4.1 ou maior é um requisito não documentado (bug 1237089). Sem o six, o Keystone irá falhar na inicialização com ImportError: No module named six ou pkg_resources.DistributionNotFound: six.
  • Uma implementação experimental de domain-specific backends de identidade (por exemplo, uma configuração de LDAP única por domínio) foi iniciada em Havana mas permanece incompleta e será finalizada durante Icehouse.
  • Com o backend de atribuição LDAP, tentar remover um papel de um usuário que na verdade não o possui, acaba indvertidamente atribuindo o role ao usuário em vez disto (veja bug 1242855)

Serviço de Rede do OpenStack (Neutron)

Principais Novas Funcionalidades

Novo Nome

O projeto de rede do OpenStack possui um novo nome nesta versão: Neutron. A versão Havana vai rodar utilizando arquivos de configuração do Quantum Grizzly; entretanto o uso do Quantum está deprecado e implantadores devem atualizar todas referências o mais breve possível. Suporte para os arquivos de configuração do Quantum e nomes de executáveis serão descartados em 2014.1 (Icehouse).

Serviços Avançados

Neutron adicionou dos novos serviços avançados durante o último ciclo de desenvolvimento e revisou o serviço de balanceamento de carga.

Load Balancer (LBaaS) anteriormente lançado como uma funcionalidade experimental na versão 2013.1 (Grizzly), o serviço de balanceamento de carga e as extensões de API agora são adequadas para implantação. Esta versão inclui uma API atualizada e com suporte ao controlador HAProxy. Controladores de fabricantes são esperados na Icehouse e Radware já liberou três controladores compatíveis com Havana para download. O serviço de balanceamento de carga pode rodar em múltiplos nodos de rede.

VPN (VPNaaS) VPNs IPSec Site-a-Site são agora suportadas via o plugin de serviço VPN. A API VPN suporta IPSec e agente L3 e inclui um controlador OpenSwan.

Firewall (FWaas) Um novo serviço de firewall de borda foi incluído nesta versão. O serviço de firewall permite que um tenant configure em detalhes a seguranças já que as regras podem ser aplicadas tanto na API de firewall e no VIF via a API de grupo de segurança. a API FWaaaS e controladores são considerados experimentais e o Neutron irá continuar o desenvolvimento durante o próximo ciclo de versão. O time agradece o feedback da comunidade para estas extensões.

Novos Plugins

Modular Layer 2 (ML2) O plugin Modular Layer 2 (ML2) é um novo plugin OpenSource para o Neutron. Este plugin é um framework que permite que a o serviço de rede do OpenStack utilize simultâneamente uma variedade de tecnologias de rede de camada 2 encontradas em data centers complexos do mundo real. Atualmente funciona com Open vSwitch, Linux Bridge e agentes L2. O plugin ML2 suporta tipos de rede local, flat, VLAN, FRE e VXLAN via controladores de tipo e controladores de mecanismo diferente. Existem controladores de fabricantes para Arista, Cisco Nexus,Hyper-V e Tail-f NCS. ML2 é um substituto para plugins Linux Bridge e Open vSwitch que agora são considerados deprecados. Mais informações sobre ML2

Outras Funcionalidades

  • Suporte para opções de boot PXE quando criando uma porta
  • Suporte melhorado de tradução

Problemas Conhecidos

Atualizações do Grizzly

Iniciar o neutron-server após atualizar o código, mas antes da migração irá resultar em alguns modelos de base de dados serem criados sem a correta migração. As seguintes definições de atulização devem ser realizadas para garantir uma base de dados corretamente atualizada.

  • Certifique-se que a base de dados aponta para Grizzly antes de parar o serviço. quantum-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini stamp grizzly
  • Pare o quantum-server e implante o código Neutron "Não inicie o neutron-server neste momento"
  • Rode o código de migração do Havana neutron-db-manage --config-file /caminho/para/quantum.conf --config-file /caminho/para/plugin/conf.ini upgrade havana
  • Inicie o neutron-server

Agentes Podem Reportar um Host Name Diferente

Neutron mudou a maneira de determinar o nome do host de utilizar o FQDN do host para o resultado retornado pela chamada gethostname(2). A Alteração foi feita para ser consistente com o resto do OpenStack. O hostname reportado por um agente pode ser diferente e irá mudar após a atualização dos agentes para Havana. Sendo assim, é necessário reagendar todas redes para os novos nomes de agente l3 e DHCP para reestabelecer o serviço. Esta mudança irá resultar em uma breve interrupçõa dos dados enquanto o implantador reagenda a rede.

Agente L3 Não Envia Mais ARPs Gratuitos por Padrão

O padrão anterior do agente L3 era enviar ARPs gratuitos. As chamadas para enviar ARPs gratuitos causavam pânicos no kernel quando implantadas utilizando namespaces de rede em algumas distribuições. Implantadores podem habilitar ARP gratuiro definindo send_arp_for_ha=3 no arquivo de configuração do agente L3.

Firewall como um Serviço

As extensões de API experimental FWaaS suporta apenas uma politica ativa por tenant. O comportamento irá mudar durante o ciclo de desenvolvimento Icehouse para permitir diferentes políticas serem anexadas em diferentes roteadores de tenant.

Notas de Atualização

  • Alterações no neutron-dhcp-agent requerem que você primeiro faça o upgrade dos dhcp-agents. Então esperar até o tempo de dhcp_lease expirar. Após isto, atualizar o neutron-server. Falhar ao fazer isto pode levar à casos onde uma instância é excluída e o processo dnsmasq não liberou o IP e o neutron aloca aquele IP para uma nova porta. (https://review.openstack.org/#/c/37580/)
  • Existe um novo arquivo policy.json. Implantadores com implantações existentes deve atualizar seus arquivos pois muitas opções mudaram. policy.json

Avisos de Deprecação

  • O uso de "quantum" ou "Quantum" em arquivos de configuração e nomes de executáveis está oficialmente deprecado. Esta é a última versão que irá suportar estes nomes e novas implantações devem utilizar nomes Neutron adequados para estes valores. Suporte para compatiblidade irá existir apenas nesta versão.
  • Os plugin de Linux Bridge e Open vSwitch foram congelados em termos de novas funcionalidades e serão removidos na versão J (2014.1). Novas implantações devem escolher ML2 em vez dos plugins individuais Linux Bridge e Open vSwitch.

Armazenamento de Bloco OpenStack (Cinder)

Principais Novas Funcionalidades

  • Migração de Volume - API de admin para migrar um volume para um backend Cinder diferente
  • Extensão de dicas do agendador adicionada na API V2
  • Adicionado controlador de armazenamento de bloco local para permitir o uso de discos raw sem LVM
  • Adicionada habilidade de estender o tamanhho de um volume existente
  • Adicionada habilidade de transferir volumes de um tenant para outro
  • Adicionada chamada de API para habilitar a edição da definição de cota padrão
  • Adicionada opção de configuração para permitir auto-flatten de snapshots para backends que deixam uma dependência quando criam volumes de snapshot.
  • Adicionada API para aceitar um nome de host na anexação de volume e não apenas um UUID de instância
  • Habilita a camada de backup generalizada para permitir backups de qualquer dispositivo iSCSI que não possui otimizações internas
  • Adicionado controlador Ceph para serviço de backup (permitindo Ceph como um destino de backup com backups diferenciais de Ceph para Ceph)
  • Adicionada informação de limitação de taxa para fornecer informações que podem ser passadas para Nova e utilizadas pelo hypervisor
  • Novas funcionalidades do Servidor de Armazenamento Windows (blueprint)

Controladores de Novos Fabricantes

  • Controlador de volume Dell EqualLogic
  • Controlador Cinder VMware VMDK
  • Sistema de arquivos IBM General Parallel File System (GPFS)

Principais Novidades dos Controladores Existentes

  • Adicionados Controladores Fibre Channel para sistemas de armazenamento Huawei
  • Adicionado um Controlador de Volume NFS para suportar armazenamento Nexenta no Cinder
  • Atualizações de miscelânea, e adições específicas de dispositivos aos controladores existentes também foram realizadas para quase todos controladores de fabricantes existentes
  • Otimizada a migração de volume para o controlador IBM Storwize

Novos Drivers de Backup

  • Permitir Ceph como uma opção para backup de volume
  • Gerenciador de Armazenamento IBM Tivoli Storage Manager (TSM)

Problemas Conhecidos

  • Bug #1237338 : Upload de volume para imagem falha com controlador de volume VMWare
  • Bug: #1240299 : Operação de limpeza de volume é chamada em todas exclusões de LVM mesmo com provisionamento thin. Até a correção, certifique-se de definir volume_clear=None em cinder.conf

Notas de Atualização

  • A funcionalidade do driver de volume ThinLVM agora faz parte do driver padrão de volume ISCSI LVM. A configuração deve ser atualizado para usar volume_driver = "cinder.volume.drivers.lvm.LVMISCSIDriver" e defina a opção lvm_type = "thin". Isto será feito automaticamente para compatibilidade com Havana se a opção volume_driver é definida como "cinder.volume.drivers.lvm.ThinLVMVolumeDriver", mas a versão Icehouse exigirá que estas opções sejam atualizadas em cinder.conf.

Medição OpenStack (Ceilometer)

Principais Novas Funcionalidades

API

  • O endpoint de estatísticas pode agora ser utilizado para agrupar amostras por alguns campos utilizando o argumento "groupby"
  • Uma nova API de alarmes agora está dispon´viel (veja "Alarmes")
  • Usuários agora podem publicar suas próprias amostras e medidores através da API.

Alarmes

Alarmes são uma nova funcionalidade que permite aos usuários e operadores disparar ações baseadas na comparação de tendências de estatísticas contra um limite durante um período de tempo. Eles são compostos dos seguintes serviços:

  • ceilometer-api agora expõe o novo endpoint /v2/alarms fornecendo controle sobre o ciclo de vida dos alarmes;
  • ceilometer-alarm-evaluator avalia os alarmes periodicamente para detectar quando um estado de alarm é alterado;
  • ceilometer-alarm-notifier recebe notificações enviadas pelo ceilometer-alarm-evaluator quando um alarme é disparado e executa a ação associada

A API de alarmes também expõe o histórico de transições de estados de alarme e alterações de regras.

Coletor

  • Novo controlador HBase
  • Novo controlador DB2 (NoSQL)
  • Melhorado o controlador SQLAlchemy
  • Melhorado o controlador MongoDB
  • Adicionada uma funcionalidade TTL que permite a exclusão de amostras antigas da base de dados
  • Adicionada a habilidade de armazenar eventos
  • Adicionada funcionalidade de armazenamento de eventos no SQLAlchemy

Controladores de Publicação

  • Adicionado um publicador baseado em UDP

Transformadores

  • Adicionados novos transformadores de unidade escalável com taxa de mudança

Medidores

  • Adicionado um medidor nas requisições de API utilizando um middleware Python especial
  • Adicionada a habilidade de armazenar amostras para a nova funcionalidade de medição de largura de banda do Neutron

Agente de Computação

  • Adicionado suporte para Hyper-V

Problemas Conhecidos

Orquestração OpenStack (Heat)

Principais Novas Funcionalidades

Documentação Muito Melhor

Integração Inicial com Tempest

Operações de recursos concorrentes

  • Criação, atualização e exclusão não dependente, realizadas agora em paralelo

Suporte de rede/Neutron Muito Melhor

  • Novos recursos LBaaS, FWaaS e VPNaaS

Suporte inicial para linguagem de modelos nativa (HOT)

: Note que o HOT ainda está sob desenvolvimento pesado, e é possível que a especificação mude (nós definitivamente estamos adicionando coisas), então trate isto como uma prévia e continue utilizando a sintaxe de modelos CFN se a estabilidade de interface é importante para você.

Abstrações de Provedor e de Ambiente

  • Abstrações para fornecer uma maneira de customizar tipos de recursos utilizando modelos aninhados, veja a documentação e o blog

Integração Ceilometer para métricas/monitoramente/alarmes

  • Adiciona um novo tipo de recurso OS::Ceilometer::Alarm que configura um alarme ceilometer
  • Além disto nós temos integração com alarmes do Ceilometer para ações de AutoScaling, que agora são disparadas por alarmes do Ceilometer. O mecanismo anterior onde métricas/alarmes processados pelo Heat ainda existe, mas agora é deprecado e será provavelmente removido durante a versão Icehouse.

Melhorias no UpdateStack

  • Vários tipos de recursos agora fornecem um suporte melhor para atualizações não destrutivas, incluindo o redimensionamento de uma instância. Além disto, criamos agora recursos de substituição antes de excluir o recurso anterior permitindo uma melhor continuidade de capacidade de roll-back.

Integração inicial com funcionalidade de trusts do keystone

  • Integração inicial com trusts do keystone, então quando heat.conf especifica deferred_auth_method=trusts, não armazenamos mais credenciais encriptadas para realizar operações postergadas (por exemplo ajustes de AutoScaling), mas em vez disto cria um trust e armazena o ID do trust.
  • (Veja os problemas conhecidos abaixo)

Documentação de recursos melhorada


Muito mais tipos de recursos nativos

Novos Tipos de Recursos Rackspace

  • Rackspace::Cloud::DBInstance
  • Rackspace::Cloud::LoadBalancer
  • Rackspace::Cloud::Server

Suspender/resumir stack

  • Suporte para um novo caminho de "ações" de API, que habilita suspender/resumir o stack

Configuração consolidada para um único heat.conf e paste-api.ini

  • Veja notas de atualização abaixo
  • Também adicionadas novas configurações de opções que fornecem limitações de
tamanho de modelo
número de stacks por tenant
número de eventos por stack
profundidade de aninhamento de stack

Modo Heat Standalone

  • Heat agora pode ser configurado para rodar em modo standalone, permitindo ele orquestrar um OpenStack externo

Problemas Conhecidos

  • heat não suporta espeficar o nome de região quando busca os endpoints de API do keystone, veja bug
  • Integração com keystone trusts (deferred_auth_method=trusts) irá funcionar apenas com o último keystoneclient 0.4.1, entretanto isto não está refletido ainda no requirements.txt do Heat
https://bugs.launchpad.net/python-keystoneclient/+bug/1231483
  • Integração com trusts de keystone requer ao menos o RC3 do keystone devido à este problema
https://bugs.launchpad.net/keystone/+bug/1239303

Notas de Atualização

  • Heat utiliza agora um arquivo de configuração (/etc/heat/heat.conf) em vez de um arquivo por serviço.
  • Os processos de API utilizam agora uma única configuração de paste (/etc/heat/api-paste.ini) em vez de um arquivo por serviço.
  • Existe agora suporte para uma definição de ambiente global em /etc/heat/environment.d/ (veja environment documentation)
  • Todos recursos OS::Neutron* foram renomeados para "OS::Quantum*", os nomes antigos ainda irão funcionar se você instalar o ambiente padrão fornecido que cria apelidos dos nomes antigos para os novos recursos.

Documentação do OpenStack

Principais Funcionalidades

  • Cada página agora possui um link para reportar bugs, então você pode facilmente reportar um bug da página de documentação
  • Os manuais foram completamente reorganizados. Com a versão Havana, os seguintes guias existem:
    • Instalando do OpenStack
      • Guia de Instalação para Red Hat Enterprise Linux, CentOS, e Fedora
      • Guia de Instalação para Ubuntu 12.04 (LTS)
      • Guia de Instalação para openSUSE e SUSE Linux Enterprise Server
    • Configurando e utilizando uma nuvem OpenStack:
      • Guia do Administrador de Nuvem
      • Referência de Configuração
      • Guia de Operação
      • Guia de Alta Disponibilidade
      • Guia de Segurança
      • Guia de Imagem de Máquina Virtual
    • Utilizando o OpenStack Dashboard e os clientes de linha de comando
      • Guia de Referência Rápida da API
      • Guia do Usuário Final
      • Guia do Usuário Administrador

Problemas conhecidos

  • Alguns dos guias não estão completamente atualizados e podem não conter todas informações.