Jump to: navigation, search

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

(Translation Team)
(Trove Databases)
Line 317: Line 317:
 
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.
 
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.
  
===== Trove Databases =====
+
===== Bases de Dados Trove =====
  
The OpenStack Database as a Service project (Trove) graduated from incubation
+
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.
in the Havana cycle, and thanks to their industriousness they delivered a
 
set of panels for the OpenStack dashboard to allow for provisioning and managing
 
your Trove databases and backups. Disclaimer: Given that Trove's first official
 
release as an integrated project will not be until Icehouse this feature should
 
still be considered experimental and may be subject to change.
 
  
 
===== Nova Features =====
 
===== Nova Features =====

Revision as of 12:40, 24 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.

Nova Features

The number of OpenStack Compute (Nova) features that are supported in Horizon continues to grow. New features in the Havana release include:

  • Editable default quotas.
  • The ability for an administrator to reset the password of a server/instance.
  • Availability zone support.
  • Improved region support.
  • Instance resizing.
  • Improved boot-from-volume support.
  • Per-project flavor support.

All of these provide a richer set of options for controlling where, when and how instances are launched, and improving how they're managed once they're up and running.

Neutron Features

A number of important new OpenStack Networking (Neutron) features are showcased in the Havana release, most notably:

  • VPN as a Service.
  • Firewall as a Service.
  • Editable and interactive network topology visualizations.
  • Full security group and quota parity between Neutron and Nova network.

These features allow for tremendous flexibility when constructing software-defined networks for your cloud using Neutron.

User Experience Improvements

Self-Service Password Change

Empowered by changes to the Identity API v2.0 (Keystone), users can now change their own 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

Several sections of the Admin dashboard have been rearranged to more logically 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

Several new indicators have been added to inform users why they've been logged 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

Since there are many very common security group rules which users tediously 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

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.

User Experience Group

A fledgling OpenStack User Experience Group formed during the Havana cycle with 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

Less Complicated LESS Compilation: No More NodeJS

Due to outcry from various parties, and made possible by improvements in the 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

Horizon has begun the transition to using the other OpenStack projects' 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

  • Swift container and object metadata are now supported.
  • New visualizations for utilization and quotas.
  • The Cisco N1K Router plugin's additional features are available through a special additional dashboard when enabled and supported in Neutron.
  • Support for self-signed or other specified SSL certificate checking.
  • Glance image types are now configurable.
  • Sorting has been improved in many places through the dashboard.
  • API call efficiency optimizations.
  • Required fields in forms are now better indicated.
  • Session timeout can now be enabled to log out the user after a period of inactivity as a security feature.
  • Significant PEP8 and code quality compliance improvements.
  • Hundreds of bugfixes and minor user experience improvements.

Upgrade Information

Allowed Hosts

For production deployments of Horizon you must add the ALLOWED_HOSTS 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

If you have existing configurations for the OPENSTACK_KEYSTONE_BACKEND 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

Session Creation and Health Checks

If you use a health monitoring service that pings the home page combined with 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

Using the "select all" checkbox to delete large numbers of resources at once 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

Whereas Nova Network uses only the name of a security group when specifying 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

The Havana Horizon release should be fully compatible with both Havana and 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 third-party developers who have built on Horizon so far.

OpenStack Identity (Keystone)

Key New Features

  • Improved deployment flexibility
    • 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 REMOTE_USER
    • 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 keystone.token.provider.Provider interface and configure keystone to use it with [token] provider. As a result, [signing] token_format is now deprecated in favor of this new configuration option.
    • First-class support for deployment behind Apache httpd
  • New deployment features
    • Ability to cache the results of driver calls in a key-value store (for example, memcached or redis)
    • keystone-manage token_flush command to help purge expired tokens
  • New API features
    • Delegated role-based authorization to arbitrary consumers using OAuth 1.0a
    • API clients can now opt out of the service catalog being included in a token response
    • Domain role assignments can now be inherited by that domain's projects
    • Aggregated role assignments API
    • 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 kerberos is supported.
    • 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.
  • Event notifications emitted for user and project/tenant create, update, and delete operations
  • General performance improvements
  • 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.
  • 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 keystone-manage db_sync --extension=«extension-name».

Known Issues

  • six v1.4.1 or higher is an undocumented requirement (bug 1237089). Without six, Keystone will fail on startup with either ImportError: No module named six or pkg_resources.DistributionNotFound: six.
  • An experimental implementation of 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.
  • 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 bug 1242855)

OpenStack Network Service (Neutron)

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.

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.

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.

New Plugins

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. More ML2 information

Other Features

  • Support for PXE Boot Options in when creating a port
  • Improved translation support

Known Issues

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.quantum-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini stamp grizzly
  • Stop quantum-server and deploy the Neutron code Do not start the neutron-server at this time.
  • Run Havana Migration neutron-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini upgrade havana
  • Start neutron-server

Agents May Report a Different Host Name

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

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.

Firewall as a Service

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.

Upgrade Notes

  • 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/)
  • There is a new default policy.json file. Deployers with existing deployments should update their files as many options have changed: policy.json

Deprecation Notices

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

Key New Features

  • Volume migration - admin API to migrate a volume to a different Cinder back-end
  • 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 (blueprint)

New Vendor Drivers

  • Dell EqualLogic volume driver
  • VMware VMDK cinder driver
  • IBM General Parallel File System (GPFS)

Major Additions To Existing Drivers

  • Add Fibre Channel drivers for Huawei storage systems
  • 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

  • Allow Ceph as an option for volume backup
  • IBM Tivoli Storage Manager (TSM)

Known Issues

  • 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

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

OpenStack Metering (Ceilometer)

Key New Features

API

  • The statistics endpoint can now be used to group samples by some fields using the groupby argument
  • A new alarm API is now available (see Alarms)
  • Users can now post their own samples and meters through the API

Alarms

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:

  • ceilometer-api now exposes the new /v2/alarms endpoint providing control over alarm lifecycle;
  • ceilometer-alarm-evaluator evaluates alarms periodically in order to detect detects when an alarm state changes;
  • ceilometer-alarm-notifier receives notifications sent by ceilometer-alarm-evaluator when an alarm is triggered and executes the associated action

The alarm API also exposes the history of alarm state transitions and rule changes.

Collector

  • New HBase driver
  • New DB2 (NoSQL) driver
  • Improved SQLAlchemy driver
  • Improved MongoDB driver
  • Added a TTL functionality that allows to delete old samples from the database
  • Added the ability to store events
  • Added event storage feature on SQLAlchemy

Publisher drivers

  • Added a UDP based publisher

Transformers

  • Added new unit-scaling and rate-of-change transformers

Meters

  • Added a meter on API requests using a special Python middleware
  • Added the ability to record samples from the new Neutron bandwidth metering feature

Compute agent

  • Added support for Hyper-V

Known Issues


OpenStack Orchestration (Heat)

Key New Features

Much improved documentation

Initial integration with Tempest

Concurrent resource operations

  • Non dependent create, update and delete operations are now performed in parallel

Much improved networking/Neutron support

  • New LBaaS, FWaaS and VPNaaS resources

Initial support for native template language (HOT)

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

Provider and Environment abstractions

  • Abstractions to provide a way to customize resource types using nested templates see documentation and blog post

Ceilometer integration for metrics/monitoring/alarms

  • Adds a new resource type 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

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

Initial integration with keystone trusts functionality

  • 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.
  • (see known issues below)

Improved resource documentation

Many more native resource types

New Rackspace resource types

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

Stack suspend/resume

  • Support for a new API "actions" path, which enables stack suspend/resume

Consolidated configuration to a single heat.conf and a single paste-api.ini

  • See upgrade notes below
  • Also added new config options to provide limitations on:
template size
number of stacks per tenant
number of events per stack
stack nesting depth

Heat Standalone Mode

  • Heat can now be configured to run in standalone mode, allowing it to orchestrate onto an external OpenStack

Known Issues

  • Heat does not support specifying region name when getting API endpoints from keystone see 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
https://bugs.launchpad.net/python-keystoneclient/+bug/1231483
  • Integration with keystone trusts requires at least RC3 of keystone due to this issue
https://bugs.launchpad.net/keystone/+bug/1239303

Upgrade Notes

  • Heat now uses one config file (/etc/heat/heat.conf) instead of per-service files.
  • The API processes now use a single paste configuration file (/etc/heat/api-paste.ini) instead of per-service files.
  • There is now support for a global environment definition in /etc/heat/environment.d/ (see 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.

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.