Jump to: navigation, search

ReleaseNotes/Havana/pt BR

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.