#, fuzzy msgid "" msgstr "" "Project-Id-Version: openstack-ansible 30.0.0.0b2.dev15\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2024-11-13 01:15+0000\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../../../inventory/dynamic_inventory.py:docstring dynamic_inventory.args:1 #: of msgid "Setup argument Parsing." msgstr "" #: ../../source/reference/architecture/container-networking.rst:4 msgid "Container networking" msgstr "" #: ../../source/reference/architecture/container-networking.rst:6 msgid "" "OpenStack-Ansible deploys Linux containers (LXC) and uses Linux or Open " "vSwitch-based bridging between the container and the host interfaces to " "ensure that all traffic from containers flows over multiple host interfaces. " "All services in this deployment model use a *unique* IP address." msgstr "" #: ../../source/reference/architecture/container-networking.rst:11 #: ../../source/reference/architecture/metal-networking.rst:12 msgid "" "This appendix describes how the interfaces are connected and how traffic " "flows." msgstr "" #: ../../source/reference/architecture/container-networking.rst:13 #: ../../source/reference/architecture/metal-networking.rst:14 msgid "" "For more information about how the OpenStack Networking service (Neutron) " "uses the interfaces for instance traffic, please see the `OpenStack " "Networking Guide`_." msgstr "" #: ../../source/reference/architecture/container-networking.rst:19 #: ../../source/reference/architecture/metal-networking.rst:20 msgid "" "For details on the configuration of networking for your environment, please " "have a look at :ref:`openstack-user-config-reference`." msgstr "" #: ../../source/reference/architecture/container-networking.rst:23 #: ../../source/reference/architecture/metal-networking.rst:24 msgid "Physical host interfaces" msgstr "" #: ../../source/reference/architecture/container-networking.rst:25 msgid "" "In a typical production environment, physical network interfaces are " "combined in bonded pairs for better redundancy and throughput. Avoid using " "two ports on the same multiport network card for the same bonded interface, " "because a network card failure affects both of the physical network " "interfaces used by the bond. Single (bonded) interfaces are also a supported " "configuration, but will require the use of VLAN subinterfaces." msgstr "" #: ../../source/reference/architecture/container-networking.rst:33 #: ../../source/reference/architecture/metal-networking.rst:35 msgid "Linux Bridges/Switches" msgstr "" #: ../../source/reference/architecture/container-networking.rst:35 #: ../../source/reference/architecture/metal-networking.rst:37 msgid "" "The combination of containers and flexible deployment options requires " "implementation of advanced Linux networking features, such as bridges, " "switches, and namespaces." msgstr "" #: ../../source/reference/architecture/container-networking.rst:39 msgid "" "Bridges provide layer 2 connectivity (similar to physical switches) among " "physical, logical, and virtual network interfaces within a host. After a " "bridge/switch is created, the network interfaces are virtually plugged in to " "it." msgstr "" #: ../../source/reference/architecture/container-networking.rst:44 #: ../../source/reference/architecture/metal-networking.rst:46 msgid "" "OpenStack-Ansible uses Linux bridges for control plane connections to LXC " "containers, and can use Linux bridges or Open vSwitch-based bridges for data " "plane connections that connect virtual machine instances to the physical " "network infrastructure." msgstr "" #: ../../source/reference/architecture/container-networking.rst:49 #: ../../source/reference/architecture/metal-networking.rst:51 msgid "" "Network namespaces provide logically separate layer 3 environments (similar " "to VRFs) within a host. Namespaces use virtual interfaces to connect with " "other namespaces, including the host namespace. These interfaces, often " "called ``veth`` pairs, are virtually plugged in between namespaces similar " "to patch cables connecting physical devices such as switches and routers." msgstr "" #: ../../source/reference/architecture/container-networking.rst:56 msgid "" "Each container has a namespace that connects to the host namespace with one " "or more ``veth`` pairs. Unless specified, the system generates random names " "for ``veth`` pairs." msgstr "" #: ../../source/reference/architecture/container-networking.rst:60 msgid "" "The following image demonstrates how the container network interfaces are " "connected to the host's bridges and physical network interfaces:" msgstr "" #: ../../source/reference/architecture/container-networking.rst:67 #: ../../source/reference/architecture/metal-networking.rst:59 msgid "Network diagrams" msgstr "" #: ../../source/reference/architecture/container-networking.rst:70 msgid "Hosts with services running in containers" msgstr "" #: ../../source/reference/architecture/container-networking.rst:72 #: ../../source/reference/architecture/metal-networking.rst:64 msgid "" "The following diagram shows how all of the interfaces and bridges " "interconnect to provide network connectivity to the OpenStack deployment:" msgstr "" #: ../../source/reference/architecture/container-networking.rst:78 msgid "" "The bridge ``lxcbr0`` is configured automatically and provides connectivity " "for the containers (via eth0) to the outside world, thanks to dnsmasq (dhcp/" "dns) + NAT." msgstr "" #: ../../source/reference/architecture/container-networking.rst:84 msgid "" "If you require additional network configuration for your container " "interfaces (like changing the routes on eth1 for routes on the management " "network), please adapt your ``openstack_user_config.yml`` file. See :ref:" "`openstack-user-config-reference` for more details." msgstr "" #: ../../source/reference/architecture/container-networking.rst:90 #: ../../source/reference/architecture/metal-networking.rst:70 msgid "Neutron traffic" msgstr "" #: ../../source/reference/architecture/container-networking.rst:92 #: ../../source/reference/architecture/metal-networking.rst:72 msgid "" "Common reference drivers, including ML2/LXB, ML2/OVS, and ML2/OVN, and their " "respective agents, are responsible for managing the virtual networking " "infrastructure on each node. OpenStack-Ansible refers to Neutron traffic as " "\"data plane\" traffic, and can consist of flat, vlan, or overlay " "technologies such as VXLAN and GENEVE." msgstr "" #: ../../source/reference/architecture/container-networking.rst:98 #: ../../source/reference/architecture/metal-networking.rst:78 msgid "" "Neutron agents can be deployed across a variety of hosts, but are typically " "limited to dedicated network hosts or infrastructure hosts (controller " "nodes). Neutron agents are deployed \"on metal\" and not within an LXC " "container. Neutron typically requires the operator to define \"provider " "bridge mappings\", which map a provider network name to a physical interface." " These provider bridge mappings provide flexibility and abstract physical " "interface names when creating provider networks." msgstr "" #: ../../source/reference/architecture/container-networking.rst:106 msgid "LinuxBridge Example:" msgstr "" #: ../../source/reference/architecture/container-networking.rst:112 msgid "Open vSwitch/OVN Example:" msgstr "" #: ../../source/reference/architecture/container-networking.rst:118 #: ../../source/reference/architecture/metal-networking.rst:98 msgid "" "OpenStack-Ansible provides two overrides when defining provider networks " "that can be used for creating the mappings and in some cases, connecting the " "physical interfaces to provider bridges:" msgstr "" #: ../../source/reference/architecture/container-networking.rst:122 #: ../../source/reference/architecture/metal-networking.rst:102 msgid "``host_bind_override``" msgstr "" #: ../../source/reference/architecture/container-networking.rst:123 #: ../../source/reference/architecture/metal-networking.rst:103 msgid "``network_interface``" msgstr "" #: ../../source/reference/architecture/container-networking.rst:125 #: ../../source/reference/architecture/metal-networking.rst:105 msgid "" "The ``host_bind_override`` override is used for LinuxBridge-based " "deployments, and requires a physical interface name which will then be used " "by the LinuxBridge agent for flat and vlan-based provider and tenant network " "traffic." msgstr "" #: ../../source/reference/architecture/container-networking.rst:129 #: ../../source/reference/architecture/metal-networking.rst:109 msgid "" "The ``network_interface`` override is used for Open vSwitch and OVN-based " "deployments, and requires a physical interface name which will be connected " "to the provider bridge (ie. br-ex) for flat and vlan-based provider and " "tenant network traffic." msgstr "" #: ../../source/reference/architecture/container-networking.rst:135 msgid "" "Previous versions of OpenStack-Ansible utilized a bridge named ``br-vlan`` " "for flat and vlan-based provider and tenant network traffic. The ``br-vlan`` " "bridge is a leftover of containerized Neutron agents and is no longer useful " "or recommended." msgstr "" #: ../../source/reference/architecture/container-networking.rst:140 #: ../../source/reference/architecture/metal-networking.rst:113 msgid "" "The following diagrams reflect the differences in the virtual network layout " "for supported network architectures." msgstr "" #: ../../source/reference/architecture/container-networking.rst:144 #: ../../source/reference/architecture/metal-networking.rst:152 msgid "Open Virtual Network (OVN)" msgstr "" #: ../../source/reference/architecture/container-networking.rst:148 #: ../../source/reference/architecture/metal-networking.rst:156 msgid "" "The ML2/OVN (LXB) mechanism driver is deployed by default as of the Zed " "release of OpenStack-Ansible." msgstr "" #: ../../source/reference/architecture/container-networking.rst:152 #: ../../source/reference/architecture/container-networking.rst:172 #: ../../source/reference/architecture/container-networking.rst:187 #: ../../source/reference/architecture/metal-networking.rst:125 #: ../../source/reference/architecture/metal-networking.rst:140 #: ../../source/reference/architecture/metal-networking.rst:160 msgid "Networking Node" msgstr "" #: ../../source/reference/architecture/container-networking.rst:158 #: ../../source/reference/architecture/container-networking.rst:178 #: ../../source/reference/architecture/container-networking.rst:193 #: ../../source/reference/architecture/metal-networking.rst:131 #: ../../source/reference/architecture/metal-networking.rst:146 #: ../../source/reference/architecture/metal-networking.rst:166 msgid "Compute Node" msgstr "" #: ../../source/reference/architecture/container-networking.rst:164 #: ../../source/reference/architecture/metal-networking.rst:117 msgid "LinuxBridge" msgstr "" #: ../../source/reference/architecture/container-networking.rst:168 #: ../../source/reference/architecture/metal-networking.rst:121 msgid "" "The ML2/LinuxBridge (LXB) mechanism driver is marked as \"experimental\" as " "of the Zed release of OpenStack-Ansible." msgstr "" #: ../../source/reference/architecture/container-networking.rst:184 #: ../../source/reference/architecture/metal-networking.rst:137 msgid "Open vSwitch (OVS)" msgstr "" #: ../../source/reference/architecture/index.rst:3 msgid "Architecture" msgstr "" #: ../../source/reference/architecture/index.rst:5 msgid "" "Many operational requirements have been taken into consideration for the " "design of the OpenStack-Ansible project." msgstr "" #: ../../source/reference/architecture/index.rst:8 msgid "" "In this chapter, you can find details about `why` OpenStack-Ansible was " "architected in this way." msgstr "" #: ../../source/reference/architecture/manifesto.rst:2 msgid "OpenStack-Ansible Manifesto" msgstr "" #: ../../source/reference/architecture/manifesto.rst:4 #: ../../source/reference/architecture/manifesto.rst:13 msgid "" "This project will be a **Batteries included** project. Which means deployer " "can expect that deploying from any of the named feature branches or tags " "should provide an OpenStack cloud built for production which will be " "available at the successful completion of the deployment." msgstr "" #: ../../source/reference/architecture/manifesto.rst:11 msgid "Project scope" msgstr "" #: ../../source/reference/architecture/manifesto.rst:18 msgid "" "However, this project solely focuses on the deployment of OpenStack and its " "requirements." msgstr "" #: ../../source/reference/architecture/manifesto.rst:21 msgid "" "This project does **not** PXE boot hosts. Host setup and lifecycle " "management is left to the deployer. This project also requires that bridges " "are setup within the hosts to allow the containers to attach to a local " "bridge for network access. See also the :dev_docs:`Container networking " "`." msgstr "" #: ../../source/reference/architecture/manifesto.rst:29 msgid "Ansible Usage" msgstr "" #: ../../source/reference/architecture/manifesto.rst:31 msgid "" "Ansible provides an automation platform to simplify system and application " "deployment. Ansible manages systems by using Secure Shell (SSH) instead of " "unique protocols that require remote daemons or agents." msgstr "" #: ../../source/reference/architecture/manifesto.rst:35 msgid "" "Ansible uses playbooks written in the YAML language for orchestration. For " "more information, see `Ansible - Intro to Playbooks `_." msgstr "" #: ../../source/reference/architecture/manifesto.rst:39 msgid "" "Ansible is a simple yet powerful orchestration tool that is ideally equipped " "for deploying OpenStack-powered clouds. The declarative nature of Ansible " "allows the deployer to turn an entire deployment into a rather simple set of " "instructions." msgstr "" #: ../../source/reference/architecture/manifesto.rst:44 msgid "" "Roles within the Openstack-Ansible umbrella are built using Ansible best " "practices and contain namespaced variables that are *human* understandable. " "All roles are independant of each other and testable separately." msgstr "" #: ../../source/reference/architecture/manifesto.rst:49 msgid "" "All roles are built as Galaxy compatible roles even when the given role is " "not intended for standalone use. While the project will offer a lot of built-" "in roles the deployer will be able to pull down or override roles with " "external ones using the built-in Ansible capabilities. This allows extreme " "flexibility for deployers." msgstr "" #: ../../source/reference/architecture/manifesto.rst:56 msgid "Source based deployments" msgstr "" #: ../../source/reference/architecture/manifesto.rst:58 msgid "" "When the OpenStack-Ansible project was created, it was required to provide a " "system able to override any OpenStack upstream source code." msgstr "" #: ../../source/reference/architecture/manifesto.rst:62 msgid "" "This means that OpenStack services and their python dependencies are built " "and installed from source code as found within the OpenStack Git " "repositories by default, but allow deployers to point to their own " "repositories." msgstr "" #: ../../source/reference/architecture/manifesto.rst:67 msgid "This also allows developers to point to their own code for their work." msgstr "" #: ../../source/reference/architecture/manifesto.rst:70 msgid "" "A source based deployment, for Python-built parts of OpenStack, makes sense " "when dealing with scale and wanting consistency over long periods of time. A " "deployer should have the ability to deploy the same OpenStack release on " "every node throughout the life cycle of the cloud, even when some components " "are end of life. By providing a repository of the sources, the deployment " "can be re-created even years after the initial deployment, assuming the " "underlying operating systems and packages stay the same." msgstr "" #: ../../source/reference/architecture/manifesto.rst:80 msgid "" "This means that there will never be a time where OpenStack specific " "packages, as provided by the distributions, are being used for OpenStack " "services. Third party repositories like *CloudArchive* and or *RDO* may " "still be required within a given deployment but only as a means to meet " "application dependencies." msgstr "" #: ../../source/reference/architecture/manifesto.rst:88 msgid "Containerized deployments" msgstr "" #: ../../source/reference/architecture/manifesto.rst:90 msgid "" "This project introduces containers as a means to abstract services from one " "another." msgstr "" #: ../../source/reference/architecture/manifesto.rst:93 msgid "" "The use of containers allows for additional abstractions of entire " "application stacks to be run all within the same physical host machines." msgstr "" #: ../../source/reference/architecture/manifesto.rst:96 msgid "" "The \"containerized\" applications are sometimes grouped within a single " "container where it makes sense, or distributed in multiple containers based " "on application and or architectural needs." msgstr "" #: ../../source/reference/architecture/manifesto.rst:100 msgid "" "The default container architecture has been built in such a way to allow for " "scalability and highly available deployments." msgstr "" #: ../../source/reference/architecture/manifesto.rst:103 msgid "" "The simple nature of machine containers allows the deployer to treat " "containers as physical machines. The same concepts apply for machine " "containers and physical machines: This will allow deployers to use existing " "operational tool sets to troubleshoot issues within a deployment and the " "ability to revert an application or service within inventory to a known " "working state without having to re-kick a physical host." msgstr "" #: ../../source/reference/architecture/manifesto.rst:110 msgid "" "Not all services are containerized: some don't make sense to run within a " "container. Logic needs to be applied in regards on how services are " "containerized. If their requirements can't be met due to system limitations, " "(kernel, application maturity, etc...), then the service is not set to run " "within a container." msgstr "" #: ../../source/reference/architecture/manifesto.rst:116 msgid "Example of un-containerized services:" msgstr "" #: ../../source/reference/architecture/manifesto.rst:118 msgid "Nova compute (for direct access to virtualization devices)" msgstr "" #: ../../source/reference/architecture/manifesto.rst:119 msgid "Swift storage (for direct access to drive)" msgstr "" #: ../../source/reference/architecture/manifesto.rst:121 msgid "" "The containers are not a mean of securing a system. The containers were not " "chosen for any eventual security safe guards. The machine containers were " "chosen because of their practicality with regard to providing a more uniform " "OpenStack deployment. Even if the abstractions that the containers provides " "do improve overall deployment security these potential benefits are not the " "intention of the containerization of services." msgstr "" #: ../../source/reference/architecture/metal-networking.rst:4 msgid "Metal networking" msgstr "" #: ../../source/reference/architecture/metal-networking.rst:6 msgid "" "OpenStack-Ansible supports deploying OpenStack and related services on " "\"metal\" as well as inside LXC containers. Python virtual environments " "(venvs) provide OpenStack service and Python library segregation, while " "other services such as Galera and RabbitMQ are co-located on the host. All " "services in this deployment model share the *same* IP address." msgstr "" #: ../../source/reference/architecture/metal-networking.rst:26 msgid "" "In a typical production environment, physical network interfaces are " "combined in bonded pairs for better redundancy and throughput. Avoid using " "two ports on the same multiport network card for the same bonded interface, " "because a network card failure affects both of the physical network " "interfaces used by the bond. Multiple bonded interfaces (ie. bond0, bond1) " "can be used to segregate traffic, if desired. Single (bonded) interfaces are " "also a supported configuration, but will require the use of VLAN " "subinterfaces." msgstr "" #: ../../source/reference/architecture/metal-networking.rst:41 msgid "" "Bridges provide layer 2 connectivity (similar to switches) among physical, " "logical, and virtual network interfaces within a host. After a bridge/switch " "is created, the network interfaces are virtually plugged in to it." msgstr "" #: ../../source/reference/architecture/metal-networking.rst:62 msgid "Hosts with services running on metal" msgstr "" #: ../../source/reference/architecture/metal-networking.rst:86 msgid "**LinuxBridge Example**:" msgstr "" #: ../../source/reference/architecture/metal-networking.rst:92 msgid "**Open vSwitch/OVN Example**:" msgstr "" #: ../../source/reference/architecture/security.rst:4 msgid "Security" msgstr "" #: ../../source/reference/architecture/security.rst:6 msgid "" "Security is one of the top priorities within OpenStack-Ansible (OSA), and " "many security enhancements for OpenStack clouds are available in deployments " "by default. This section provides a detailed overview of the most important " "security enhancements." msgstr "" #: ../../source/reference/architecture/security.rst:13 msgid "" "Every deployer has different security requirements. The `OpenStack Security " "Guide`_ has instructions and advice on how to operate and consume an " "OpenStack cloud by using the most secure methods." msgstr "" #: ../../source/reference/architecture/security.rst:18 msgid "Encrypted communication" msgstr "" #: ../../source/reference/architecture/security.rst:20 msgid "" "Any OpenStack cloud has sensitive information transmitted between services, " "including user credentials, service credentials or information about " "resources being created. Encrypting this traffic is critical in environments " "where the network cannot be trusted. (For more information about securing " "the network, see the :ref:`least-access-openstack-services` section.)" msgstr "" #: ../../source/reference/architecture/security.rst:27 msgid "" "Many of the services deployed with OpenStack-Ansible are encrypted by " "default or offer encryption as an option. The playbooks generate self-signed " "certificates by default, but deployers have the option to use their existing " "certificates, keys, and CA certificates." msgstr "" #: ../../source/reference/architecture/security.rst:32 msgid "" "To learn more about how to customize the deployment of encrypted " "communications, see :ref:`Securing services with SSL certificates " "`." msgstr "" #: ../../source/reference/architecture/security.rst:37 msgid "Host security hardening" msgstr "" #: ../../source/reference/architecture/security.rst:39 msgid "" "OpenStack-Ansible provides a comprehensive `security hardening role`_ that " "applies over 200 security configurations as recommended by the `Security " "Technical Implementation Guide`_ (STIG) provided by the Defense Information " "Systems Agency (DISA). These security configurations are widely used and are " "distributed in the public domain by the United States government." msgstr "" #: ../../source/reference/architecture/security.rst:45 msgid "" "Host security hardening is required by several compliance and regulatory " "programs, such as the `Payment Card Industry Data Security Standard`_ (PCI " "DSS) (Requirement 2.2)." msgstr "" #: ../../source/reference/architecture/security.rst:49 msgid "" "By default, OpenStack-Ansible automatically applies the ansible-hardening " "role to all deployments. The role has been carefully designed to perform as " "follows:" msgstr "" #: ../../source/reference/architecture/security.rst:52 msgid "Apply nondisruptively to a production OpenStack environment" msgstr "" #: ../../source/reference/architecture/security.rst:53 msgid "Balance security with OpenStack performance and functionality" msgstr "" #: ../../source/reference/architecture/security.rst:54 msgid "Run as quickly as possible" msgstr "" #: ../../source/reference/architecture/security.rst:56 msgid "" "For more information about the security configurations, see the `security " "hardening role`_ documentation." msgstr "" #: ../../source/reference/architecture/security.rst:64 msgid "Isolation" msgstr "" #: ../../source/reference/architecture/security.rst:66 msgid "" "By default, OpenStack-Ansible provides isolation by default between the " "containers that run the OpenStack infrastructure (control plane) services " "and also between the virtual machines that end users spawn within the " "deployment. This isolation is critical because it can prevent container or " "virtual machine breakouts, or at least reduce the damage that breakouts " "might cause." msgstr "" #: ../../source/reference/architecture/security.rst:72 msgid "" "The `Linux Security Modules`_ (LSM) framework allows administrators to set " "`mandatory access controls`_ (MAC) on a Linux system. MAC is different than " "`discretionary access controls`_ (DAC) because the kernel enforces strict " "policies that no user can bypass. Although any user might be able to change " "a DAC policy (such as ``chown bob secret.txt``), only the ``root`` user can " "alter a MAC policy." msgstr "" #: ../../source/reference/architecture/security.rst:79 msgid "" "OpenStack-Ansible currently uses `AppArmor`_ to provide MAC policies on " "infrastructure servers and hypervisors. The AppArmor configuration sets the " "access policies to prevent one container from accessing the data of another " "container. For virtual machines, ``libvirtd`` uses the `sVirt`_ extensions " "to ensure that one virtual machine cannot access the data or devices from " "another virtual machine." msgstr "" #: ../../source/reference/architecture/security.rst:86 msgid "" "These policies are applied and governed at the kernel level. Any process " "that violates a policy is denied access to the resource. All denials are " "logged in ``auditd`` and are available at ``/var/log/audit/audit.log``." msgstr "" #: ../../source/reference/architecture/security.rst:97 msgid "Least privilege" msgstr "" #: ../../source/reference/architecture/security.rst:99 msgid "" "The `principle of least privilege`_ is used throughout OpenStack-Ansible to " "limit the damage that could be caused if an attacker gains access to any " "credentials." msgstr "" #: ../../source/reference/architecture/security.rst:103 msgid "" "OpenStack-Ansible configures unique username and password combinations for " "each service that interacts with RabbitMQ and Galera/MariaDB. Each service " "that connects to RabbitMQ uses a separate virtual host for publishing and " "consuming messages. The MariaDB users for each service are only granted " "access only to the databases that they need to query." msgstr "" #: ../../source/reference/architecture/security.rst:111 msgid "" "You can also run OpenStack-Ansible with non-root user by leveraging the " "`Ansible privilege escalation`_ method. For more details, please reffer to " "the :doc:`running as non-root `." msgstr "" #: ../../source/reference/architecture/security.rst:120 msgid "Securing network access to OpenStack services" msgstr "" #: ../../source/reference/architecture/security.rst:122 msgid "" "OpenStack clouds provide many services to end users, that enable them to " "build instances, provision storage, and create networks. Each of these " "services exposes one or more service ports and API endpoints to the network." msgstr "" #: ../../source/reference/architecture/security.rst:126 msgid "" "However, some of the services within an OpenStack cloud are accessible to " "all end users, while others are accessible only to administrators or " "operators on a secured network." msgstr "" #: ../../source/reference/architecture/security.rst:130 msgid "Services that *all end users* can access" msgstr "" #: ../../source/reference/architecture/security.rst:132 msgid "" "These services include Compute (nova), Object Storage (swift), Networking " "(neutron), and Image (glance)." msgstr "" #: ../../source/reference/architecture/security.rst:134 msgid "" "These services should be offered on a sufficiently restricted network that " "still allows all end users to access the services." msgstr "" #: ../../source/reference/architecture/security.rst:136 #: ../../source/reference/architecture/security.rst:144 msgid "A firewall must be used to restrict access to the network." msgstr "" #: ../../source/reference/architecture/security.rst:138 msgid "Services that *only administrators or operators* can access" msgstr "" #: ../../source/reference/architecture/security.rst:140 msgid "" "These services include MariaDB, Memcached, RabbitMQ, and the admin API " "endpoint for the Identity (keystone) service." msgstr "" #: ../../source/reference/architecture/security.rst:142 msgid "" "These services *must* be offered on a highly restricted network that is " "available only to administrative users." msgstr "" #: ../../source/reference/architecture/security.rst:146 msgid "Limiting access to these networks has several benefits:" msgstr "" #: ../../source/reference/architecture/security.rst:148 msgid "Allows for network monitoring and alerting" msgstr "" #: ../../source/reference/architecture/security.rst:149 msgid "Prevents unauthorized network surveillance" msgstr "" #: ../../source/reference/architecture/security.rst:150 msgid "Reduces the chance of credential theft" msgstr "" #: ../../source/reference/architecture/security.rst:151 msgid "Reduces damage from unknown or unpatched service vulnerabilities" msgstr "" #: ../../source/reference/architecture/security.rst:153 msgid "" "OpenStack-Ansible deploys HAProxy back ends for each service and restricts " "access for highly sensitive services by making them available only on the " "management network. Deployers with external load balancers must ensure that " "the back ends are configured securely and that firewalls prevent traffic " "from crossing between networks." msgstr "" #: ../../source/reference/architecture/security.rst:159 msgid "" "For more information about recommended network policies for OpenStack " "clouds, see the `API endpoint process isolation and policy`_ section of the " "`OpenStack Security Guide`_" msgstr "" #: ../../source/reference/architecture/service-arch.rst:2 msgid "Service architecture" msgstr "" #: ../../source/reference/architecture/service-arch.rst:5 #: ../../source/reference/inventory/configure-inventory.rst:10 msgid "Introduction" msgstr "" #: ../../source/reference/architecture/service-arch.rst:7 msgid "" "OpenStack-Ansible has a flexible deployment configuration model that can " "deploy all services in separate machine containers or on designated hosts " "without using containers, and all network traffic either on a single network " "interface or on many network interfaces." msgstr "" #: ../../source/reference/architecture/service-arch.rst:12 msgid "" "This flexibility enables deployers to choose how to deploy OpenStack in the " "appropriate way for the specific use case." msgstr "" #: ../../source/reference/architecture/service-arch.rst:15 msgid "" "The following sections describe the services that OpenStack-Ansible deploys." msgstr "" #: ../../source/reference/architecture/service-arch.rst:18 msgid "Infrastructure services" msgstr "" #: ../../source/reference/architecture/service-arch.rst:20 msgid "OpenStack-Ansible deploys the following infrastructure components:" msgstr "" #: ../../source/reference/architecture/service-arch.rst:22 msgid "MariaDB with Galera" msgstr "" #: ../../source/reference/architecture/service-arch.rst:24 msgid "" "All OpenStack services require an underlying database. MariaDB with Galera " "implements a multimaster database configuration, which simplifies its use as " "a highly available database with a simple failover model." msgstr "" #: ../../source/reference/architecture/service-arch.rst:28 msgid "RabbitMQ" msgstr "" #: ../../source/reference/architecture/service-arch.rst:30 msgid "" "OpenStack services use RabbitMQ for Advanced Message Queuing Protocol (AMQP)." " OSA deploys RabbitMQ in a clustered configuration with all queues mirrored " "between the cluster nodes. Because Telemetry (ceilometer) message queue " "traffic is quite heavy, for large environments we recommend separating " "Telemetry notifications into a separate RabbitMQ cluster." msgstr "" #: ../../source/reference/architecture/service-arch.rst:36 msgid "Memcached" msgstr "" #: ../../source/reference/architecture/service-arch.rst:38 msgid "" "OpenStack services use Memcached for in-memory caching, which accelerates " "transactions. For example, the OpenStack Identity service (keystone) uses " "Memcached for caching authentication tokens, which ensures that token " "validation does not have to complete a disk or database transaction every " "time the service is asked to validate a token." msgstr "" #: ../../source/reference/architecture/service-arch.rst:44 msgid "Repository" msgstr "" #: ../../source/reference/architecture/service-arch.rst:46 msgid "" "The repository holds the reference set of artifacts that are used for the " "installation of the environment. The artifacts include:" msgstr "" #: ../../source/reference/architecture/service-arch.rst:49 msgid "" "A Git repository that contains a copy of the source code that is used to " "prepare the packages for all OpenStack services" msgstr "" #: ../../source/reference/architecture/service-arch.rst:51 msgid "Python wheels for all services that are deployed in the environment" msgstr "" #: ../../source/reference/architecture/service-arch.rst:52 msgid "" "An apt/yum proxy cache that is used to cache distribution packages installed " "in the environment" msgstr "" #: ../../source/reference/architecture/service-arch.rst:55 msgid "Load balancer" msgstr "" #: ../../source/reference/architecture/service-arch.rst:57 msgid "" "At least one load balancer is required for a deployment. OSA provides a " "deployment of `HAProxy`_, but we recommend using a physical load balancing " "appliance for production environments." msgstr "" #: ../../source/reference/architecture/service-arch.rst:61 msgid "Utility container" msgstr "" #: ../../source/reference/architecture/service-arch.rst:63 msgid "" "If a tool or object does not require a dedicated container, or if it is " "impractical to create a new container for a single tool or object, it is " "installed in the utility container. The utility container is also used when " "tools cannot be installed directly on a host. The utility container is " "prepared with the appropriate credentials and clients to administer the " "OpenStack environment. It is set to automatically use the internal service " "endpoints." msgstr "" #: ../../source/reference/architecture/service-arch.rst:71 msgid "Unbound DNS container" msgstr "" #: ../../source/reference/architecture/service-arch.rst:73 msgid "" "Containers running an `Unbound DNS`_ caching service can optionally be " "deployed to cache DNS lookups and to handle internal DNS name resolution. We " "recommend using this service for large-scale production environments because " "the deployment will be significantly faster. If this service is not used, " "OSA modifies ``/etc/hosts`` entries for all hosts in the environment." msgstr "" #: ../../source/reference/architecture/service-arch.rst:83 msgid "OpenStack services" msgstr "" #: ../../source/reference/architecture/service-arch.rst:85 msgid "" "OSA is able to deploy a multitude of services. Have a look at the role " "maturity matrix to know the status of the service you want to deploy." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:2 msgid "Storage architecture" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:4 msgid "OpenStack has multiple storage realms to consider:" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:6 #: ../../source/reference/architecture/storage-arch.rst:13 msgid "Block Storage (cinder)" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:7 #: ../../source/reference/architecture/storage-arch.rst:74 msgid "Object Storage (swift)" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:8 #: ../../source/reference/architecture/storage-arch.rst:92 msgid "Image storage (glance)" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:9 #: ../../source/reference/architecture/storage-arch.rst:134 msgid "Ephemeral storage (nova)" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:10 #: ../../source/reference/architecture/storage-arch.rst:169 msgid "Filesystem storage (manila)" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:15 msgid "" "The Block Storage (cinder) service manages volumes on storage devices in an " "environment. In a production environment, the device presents storage via a " "storage protocol (for example, NFS, iSCSI, or Ceph RBD) to a storage network " "(``br-storage``) and a storage management API to the management network " "(``br-mgmt``). Instances are connected to the volumes via the storage " "network by the hypervisor on the Compute host." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:22 msgid "" "The following diagram illustrates how Block Storage is connected to " "instances." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:27 #: ../../source/reference/architecture/storage-arch.rst:112 #: ../../source/reference/architecture/storage-arch.rst:154 msgid "The diagram shows the following steps." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:30 msgid "" "A volume is created by the assigned ``cinder-volume`` service using the " "appropriate `cinder driver`_. The volume is created by using an API that is " "presented to the management network." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:34 msgid "" "After the volume is created, the ``nova-compute`` service connects the " "Compute host hypervisor to the volume via the storage network." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:37 msgid "" "After the hypervisor is connected to the volume, it presents the volume as a " "local hardware device to the instance." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:43 msgid "" "The `LVMVolumeDriver`_ is designed as a reference driver implementation, " "which we do not recommend for production usage. The LVM storage back-end is " "a single-server solution that provides no high-availability options. If the " "server becomes unavailable, then all volumes managed by the ``cinder-" "volume`` service running on that server become unavailable. Upgrading the " "operating system packages (for example, kernel or iSCSI) on the server " "causes storage connectivity outages because the iSCSI service (or the host) " "restarts." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:52 msgid "" "Because of a `limitation with container iSCSI connectivity`_, you must " "deploy the ``cinder-volume`` service directly on a physical host (not into a " "container) when using storage back ends that connect via iSCSI. This " "includes the `LVMVolumeDriver`_ and many of the drivers for commercial " "storage devices." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:59 msgid "" "The ``cinder-volume`` service does not run in a highly available " "configuration. When the ``cinder-volume`` service is configured to manage " "volumes on the same back end from multiple hosts or containers, one service " "is scheduled to manage the life cycle of the volume until an alternative " "service is assigned to do so. This assignment can be made through the " "`cinder-manage CLI tool`_. This configuration might change if `cinder volume " "active-active support spec`_ is implemented." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:76 msgid "" "The Object Storage (swift) service implements a highly available, " "distributed, eventually consistent object/blob store that is accessible via " "HTTP/HTTPS." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:79 msgid "The following diagram illustrates how data is accessed and replicated." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:84 msgid "" "The ``swift-proxy`` service is accessed by clients via the load balancer on " "the management network (``br-mgmt``). The ``swift-proxy`` service " "communicates with the Account, Container, and Object services on the Object " "Storage hosts via the storage network(``br-storage``). Replication between " "the Object Storage hosts is done via the replication network (``br-repl``)." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:94 msgid "" "The Image service (glance) can be configured to store images on a variety of " "storage back ends supported by the `glance_store drivers`_." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:99 msgid "" "When the File System store is used, the Image service has no mechanism of " "its own to replicate the image between Image service hosts. We recommend " "using a shared storage back end (via a file system mount) to ensure that " "all ``glance-api`` services have access to all images. Doing so prevents " "losing access to images when an infrastructure (control plane) host is lost." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:105 msgid "" "The following diagram illustrates the interactions between the Image " "service, the storage device, and the ``nova-compute`` service when an " "instance is created." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:115 #: ../../source/reference/architecture/storage-arch.rst:157 msgid "1" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:115 msgid "" "When a client requests an image, the ``glance-api`` service accesses the " "appropriate store on the storage device over the storage network (``br-" "storage``) and pulls it into its cache. When the same image is requested " "again, it is given to the client directly from the cache." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:121 #: ../../source/reference/architecture/storage-arch.rst:162 msgid "2" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:121 msgid "" "When an instance is scheduled for creation on a Compute host, the ``nova-" "compute`` service requests the image from the ``glance-api`` service over " "the management network (``br-mgmt``)." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:125 #: ../../source/reference/architecture/storage-arch.rst:165 msgid "3" msgstr "" #: ../../source/reference/architecture/storage-arch.rst:125 msgid "" "After the image is retrieved, the ``nova-compute`` service stores the image " "in its own image cache. When another instance is created with the same " "image, the image is retrieved from the local base image cache." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:136 msgid "" "When the flavors in the Compute service are configured to provide instances " "with root or ephemeral disks, the ``nova-compute`` service manages these " "allocations using its ephemeral disk storage location." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:140 msgid "" "In many environments, the ephemeral disks are stored on the Compute host's " "local disks, but for production environments we recommend that the Compute " "hosts be configured to use a shared storage subsystem instead. A shared " "storage subsystem allows quick, live instance migration between Compute " "hosts, which is useful when the administrator needs to perform maintenance " "on the Compute host and wants to evacuate it. Using a shared storage " "subsystem also allows the recovery of instances when a Compute host goes " "offline. The administrator is able to evacuate the instance to another " "Compute host and boot it up again. The following diagram illustrates the " "interactions between the storage device, the Compute host, the hypervisor, " "and the instance." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:157 msgid "" "The Compute host is configured with access to the storage device. The " "Compute host accesses the storage space via the storage network (``br-" "storage``) by using a storage protocol (for example, NFS, iSCSI, or Ceph " "RBD)." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:162 msgid "" "The ``nova-compute`` service configures the hypervisor to present the " "allocated instance disk as a device to the instance." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:165 msgid "The hypervisor presents the disk as a device to the instance." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:171 msgid "" "The shared filesystem service (manila) can be configured to provide file " "systems on a variety of storage back ends as supported by the `manila_store " "drivers`_." msgstr "" #: ../../source/reference/architecture/storage-arch.rst:178 msgid "The diagram shows a basic overview of the manila service." msgstr "" #: ../../source/reference/commands/reference.rst:3 msgid "Command Line Reference" msgstr "" #: ../../source/reference/commands/reference.rst:6 msgid "Linux Container commands" msgstr "" #: ../../source/reference/commands/reference.rst:8 msgid "The following are some useful commands to manage LXC:" msgstr "" #: ../../source/reference/commands/reference.rst:10 msgid "" "List containers and summary information such as operational state and " "network configuration:" msgstr "" #: ../../source/reference/commands/reference.rst:17 msgid "" "Show container details including operational state, resource utilization, " "and ``veth`` pairs:" msgstr "" #: ../../source/reference/commands/reference.rst:24 msgid "Start a container:" msgstr "" #: ../../source/reference/commands/reference.rst:30 msgid "Attach to a container:" msgstr "" #: ../../source/reference/commands/reference.rst:36 msgid "Stop a container:" msgstr "" #: ../../source/reference/configuration/advanced-config.rst:3 msgid "Advanced configuration" msgstr "" #: ../../source/reference/configuration/advanced-config.rst:5 msgid "" "The OpenStack-Ansible project provides a basic OpenStack environment, but " "many deployers will wish to extend the environment based on their needs. " "This could include installing extra services, changing package versions, or " "overriding existing variables." msgstr "" #: ../../source/reference/configuration/advanced-config.rst:10 msgid "" "Using these extension points, deployers can provide a more 'opinionated' " "installation of OpenStack that may include their own software." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:2 msgid "Extending OpenStack-Ansible with additional Ansible content" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:5 msgid "Including OpenStack-Ansible in your project" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:7 msgid "" "Including the openstack-ansible repository within another project can be " "done in several ways:" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:10 msgid "A git submodule pointed to a released tag." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:11 msgid "A script to automatically perform a git checkout of OpenStack-Ansible." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:13 msgid "" "When including OpenStack-Ansible in a project, consider using a parallel " "directory structure as shown in the ``ansible.cfg`` files section." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:16 msgid "" "Also note that copying files into directories such as ``env.d`` or ``conf." "d`` should be handled via some sort of script within the extension project." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:21 msgid "Including OpenStack-Ansible with your Ansible structure" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:23 msgid "" "You can create your own playbook, variable, and role structure while still " "including the OpenStack-Ansible roles and libraries by setting environment " "variables or by adjusting ``/usr/local/bin/openstack-ansible.rc``." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:27 msgid "" "The relevant environment variables for OpenStack-Ansible are as follows:" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:30 msgid "" "This variable should point to ``/etc/ansible/plugins/library``. Doing so " "allows roles and playbooks to access OpenStack-Ansible's included Ansible " "modules." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:31 msgid "``ANSIBLE_LIBRARY``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:34 msgid "" "This variable should point to ``/etc/ansible/roles`` by default. This allows " "Ansible to properly look up any OpenStack-Ansible roles that extension roles " "may reference." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:36 msgid "``ANSIBLE_ROLES_PATH``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:39 msgid "" "This variable should point to ``openstack-ansible/inventory/" "dynamic_inventory.py``. With this setting, extensions have access to the " "same dynamic inventory that OpenStack-Ansible uses." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:42 msgid "``ANSIBLE_INVENTORY``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:44 msgid "" "The paths to the ``openstack-ansible`` top level directory can be relative " "in this file." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:47 msgid "Consider this directory structure::" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:58 msgid "" "The environment variables set would use ``../openstack-ansible/playbooks/" "``." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:64 msgid "Adding new or overriding roles in your OpenStack-Ansible installation" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:66 msgid "" "By default OpenStack-Ansible uses its `ansible-role-requirements`_ file to " "fetch the roles it requires for the installation process." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:69 msgid "" "The roles will be fetched into the standard ``ANSIBLE_ROLES_PATH``, which " "defaults to ``/etc/ansible/roles``." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:72 msgid "" "``ANSIBLE_ROLE_FILE`` is an environment variable pointing to the location of " "a YAML file which ansible-galaxy can consume, specifying which roles to " "download and install. The default value for this is ``ansible-role-" "requirements.yml``." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:77 msgid "" "To completely override the ansible-role-requirement file you can define the " "environment variable ``ANSIBLE_ROLE_FILE`` before running the ``bootstrap-" "ansible.sh`` script. With this approach it is now the responsibility of the " "deployer to maintain appropriate versions pins of the ansible roles if an " "upgrade is required." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:83 msgid "" "If you want to extend or just partially override content of the ``ansible-" "role-requirements.yml`` file you can create a new config file which path " "defaults to ``/etc/openstack_deploy/user-role-requirements.yml``. This path " "can be overriden with another environment variable ``USER_ROLE_FILE`` which " "is expected to be relative to ``OSA_CONFIG_DIR`` (/etc/openstack_deploy) " "folder." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:90 msgid "" "This file is in the same format as ``ansible-role-requirements.yml`` and can " "be used to add new roles or selectively override existing ones. New roles " "listed in ``user-role-requirements.yml`` will be merged with those in " "``ansible-role-requirements.yml``, and roles with matching ``name`` key will " "override those in ``ansible-role-requirements.yml``. In case when ``src`` " "key is not defined bootstrap script will skip cloning such roles." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:97 msgid "" "It is easy for a deployer to keep this file under their own version control " "and out of the openstack-ansible tree." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:102 msgid "" "Adding new or overriding collections in your OpenStack-Ansible installation" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:104 msgid "" "Alike to roles, collections for installation are stored in `ansible-" "collection-requirements`_ file. Path to this file can be overriden through " "``ANSIBLE_COLLECTION_FILE`` environmental variable." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:108 msgid "" "The Victoria release of openstack-ansible adds an optional new config file " "which defaults to ``/etc/openstack_deploy/user-collection-requirements.yml``." "" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:112 msgid "" "It should be in the native format of the ansible-galaxy requirements file " "and can be used to add new collections to the deploy host or override " "versions or source for collections defined in ``ansible-collection-" "requirements``." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:116 msgid "" "``user-collection-requirements`` will be merged with ``ansible-collection-" "requirements`` using collection ``name`` as a key. In case ``source`` is not " "defined in ``user-collection-requirements``, collection installation will be " "skipped. This way you can skip installation of unwanted collections." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:122 msgid "" "You can override location of the ``user-collection-requirements.yml`` by " "setting ``USER_COLLECTION_FILE`` environment variable before running the " "``bootstrap-ansible.sh`` script. Though it is expected to be relative to " "``OSA_CONFIG_DIR`` (/etc/openstack_deploy) folder." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:128 msgid "Calling extra playbooks during the deployment" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:130 msgid "" "If you install some additional deployment functionality as either a " "collection or a git repository on the deploy host, it is possible to " "automatically include extra playbooks at certain points during the " "deployment." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:135 msgid "" "The points where a hook exists to call an external playbook are as follows:" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:138 msgid "``pre_setup_hosts_hook``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:139 msgid "``post_setup_hosts_hook``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:140 msgid "``pre_setup_infrastructure_hook``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:141 msgid "``post_setup_infrastructure_hook``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:142 msgid "``pre_setup_openstack_hook``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:143 msgid "``post_setup_openstack_hook``" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:145 msgid "" "The hook variables should be configured in a suitable user_variables file. " "An example calling a playbook from a collection (installed using user-" "collection-requirements.yml) :" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:153 msgid "" "Installing extra playbooks using collections, and referencing the playbook " "with its FQCN is the most robust approach to including additional user " "defined playbooks." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:158 msgid "Installing extra Python packages inside Ansible virtualenv" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:160 msgid "" "Some Ansible collections may require presence of specific Python libraries " "inside execution environment. In order to accomplish that deployer can " "create ``/etc/openstack_deploy/user-ansible-venv-requirements.txt`` file " "with a list of Python libraries that should be installed inside virtual " "environment along with Ansible during ``bootstrap-ansible.sh`` execution." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:166 msgid "" "You can override the default path to ``user-ansible-venv-requirements.txt`` " "file with ``USER_ANSIBLE_REQUIREMENTS_FILE`` environment variable before " "running the ``bootstrap-ansible.sh`` script." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:172 msgid "Defining environment variables for deployment" msgstr "" #: ../../source/reference/configuration/extending-osa.rst:174 msgid "" "Throughout the documentation we talk a lot about different environment " "variables that control behaviour of OpenStack-Ansible and Ansible iteself." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:177 msgid "" "Starting with the Zed release a ``user.rc`` file can be placed in " "``OSA_CONFIG_DIR`` (/etc/openstack_deploy) folder and contain any " "environment variable definitions that might be needed to change the default " "behaviour or any arbitrary `Ansible configuration`_ parameter. These " "environment variables are general purpose and are not limited to those " "understood by Ansible." msgstr "" #: ../../source/reference/configuration/extending-osa.rst:184 msgid "" "The path to this file can be changed by setting the ``OSA_USER_RC`` " "variable, but the ``OSA_CONFIG_DIR`` and ``OSA_USER_RC`` variables cannot re-" "defined or controlled through the ``user.rc`` file." msgstr "" #: ../../source/reference/configuration/extra-networks.rst:2 msgid "Adding extra network to container" msgstr "" #: ../../source/reference/configuration/extra-networks.rst:4 msgid "" "In some cases it may be useful to have an ability to add extra network " "interface for some container group (or just a single container). As an " "example this can be used for applying known fixed IP address from another " "network for Designate service. We will show futher configuration based on " "this example. Let's assume, that this network is 10.0.20.0/24 which is " "reachable through `br-dns` interface." msgstr "" #: ../../source/reference/configuration/extra-networks.rst:11 msgid "" "To add new interface with that network into dessignate containers, we need " "to do several actions in ``openstack_user_config.yml``." msgstr "" #: ../../source/reference/configuration/extra-networks.rst:16 msgid "" "You may find detailed example of `openstack_user_config.yml` configuration " "in section :ref:`openstack-user-config-reference`." msgstr "" #: ../../source/reference/configuration/extra-networks.rst:19 msgid "Add this network in ``cidr_networks``:" msgstr "" #: ../../source/reference/configuration/extra-networks.rst:29 msgid "Describe network in ``provider_networks``:" msgstr "" #: ../../source/reference/configuration/extra-networks.rst:44 msgid "Define override for containers" msgstr "" #: ../../source/reference/configuration/extra-networks.rst:48 msgid "" "Adding gateway key will create default route inside container through it" msgstr "" #: ../../source/reference/configuration/extra-networks.rst:66 msgid "Using SR-IOV interfaces in containers" msgstr "" #: ../../source/reference/configuration/extra-networks.rst:68 msgid "" "For some deployments it might be required to passthrough devices directly to " "containers, for example, when SR-IOV is used or devices can't be bridged (ie " "with `IPoIB `)" msgstr "" #: ../../source/reference/configuration/extra-networks.rst:72 msgid "" "You would need to manually map physical interfaces to specific containers. " "This also assumes, that same interface name is present on all containers and " "it is consistent and present before LXC startup." msgstr "" #: ../../source/reference/configuration/extra-networks.rst:76 msgid "" "Below as an example we will try using IB interfaces for storage network and " "pass them inside containers that require storage connectivity. For that you " "need describe connections in ``provider_networks`` inside " "`openstack_user_config.yml` configuration:" msgstr "" #: ../../source/reference/configuration/extra-python-software.rst:2 msgid "Adding extra python software" msgstr "" #: ../../source/reference/configuration/extra-python-software.rst:4 msgid "" "The system will allow you to install and build any package that is a python " "installable. The repository infrastructure will look for and create any git " "based or PyPi installable package. When the package is built the repo-build " "role will create the sources as Python wheels to extend the base system and " "requirements." msgstr "" #: ../../source/reference/configuration/extra-python-software.rst:10 msgid "" "While the pre-built packages in the repository-infrastructure are " "comprehensive, it may be needed to change the source locations and versions " "of packages to suit different deployment needs. Adding additional " "repositories as overrides is as simple as listing entries within the " "variable file of your choice. Any ``user_.*.yml`` file within the \"/etc/" "openstack_deployment\" directory will work to facilitate the addition of a " "new packages." msgstr "" #: ../../source/reference/configuration/extra-python-software.rst:24 msgid "" "Additional lists of python packages can also be overridden using a ``user_.*." "yml`` variable file." msgstr "" #: ../../source/reference/configuration/extra-python-software.rst:35 msgid "" "Once the variables are set call the play ``repo-build.yml`` to build all of " "the wheels within the repository infrastructure. When ready run the target " "plays to deploy your overridden source code." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:4 msgid "Overriding default configuration" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:7 msgid "Variable precedence" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:10 msgid "Role defaults" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:12 msgid "" "Every role has a file, ``defaults/main.yml`` which holds the usual variables " "overridable by a deployer, like a regular Ansible role. This defaults are " "the closest possible to OpenStack standards." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:16 msgid "They can be overridden at multiple levels." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:19 msgid "Group vars and host vars" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:21 msgid "" "OpenStack-Ansible provides safe defaults for deployers in its group_vars " "folder. They take care of the wiring between different roles, like for " "example storing information on how to reach RabbitMQ from nova role." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:26 msgid "" "You can override the existing group vars (and host vars) by creating your " "own folder in /etc/openstack_deploy/group_vars (and /etc/openstack_deploy/" "host_vars respectively)." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:30 msgid "" "If you want to change the location of the override folder, you can adapt " "your openstack-ansible.rc file, or export ``GROUP_VARS_PATH`` and " "``HOST_VARS_PATH`` during your shell session." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:35 msgid "Role vars" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:37 msgid "" "Every role makes use of additional variables in ``vars/`` which take " "precedence over group vars." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:40 msgid "" "These variables are typically internal to the role and are not designed to " "be overridden. However, deployers may choose to override them using extra-" "vars by placing the overrides into the user variables file." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:46 msgid "User variables" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:48 msgid "" "If you want to globally override variable, you can define the variable you " "want to override in a ``/etc/openstack_deploy/user_*.yml`` file. It will " "apply on all hosts." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:53 msgid "user_*.yml files in more details" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:55 msgid "" "Files in ``/etc/openstack_deploy`` beginning with ``user_`` will be " "automatically sourced in any ``openstack-ansible`` command. Alternatively, " "the files can be sourced with the ``-e`` parameter of the ``ansible-" "playbook`` command." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:60 msgid "" "``user_variables.yml`` and ``user_secrets.yml`` are used directly by " "OpenStack-Ansible. Adding custom variables used by your own roles and " "playbooks to these files is not recommended. Doing so will complicate your " "upgrade path by making comparison of your existing files with later versions " "of these files more arduous. Rather, recommended practice is to place your " "own variables in files named following the ``user_*.yml`` pattern so they " "will be sourced alongside those used exclusively by OpenStack-Ansible." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:68 msgid "" "``user_*.yml`` files contain YAML variables which are applied as extra-vars " "when executing ``openstack-ansible`` to run playbooks. They will be sourced " "in alphanumeric order by ``openstack-ansible``. If duplicate variables occur " "in the ``user_*.yml`` files, the variable in the last file read will take " "precedence." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:75 msgid "Setting overrides in configuration files with config_template" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:77 msgid "" "All of the services that use YAML, JSON, or INI for configuration can " "receive overrides through the use of a Ansible action plugin named " "``config_template``. The configuration template engine allows a deployer to " "use a simple dictionary to modify or add items into configuration files at " "run time that may not have a preset template option. All OpenStack-Ansible " "roles allow for this functionality where applicable. Files available to " "receive overrides can be seen in the ``defaults/main.yml`` file as standard " "empty dictionaries (hashes)." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:85 msgid "" "This module was not accepted into Ansible Core (see `PR1`_ and `PR2`_), and " "will never be." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:92 msgid "config_template documentation" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:94 msgid "" "These are the options available as found within the virtual module " "documentation section." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:141 msgid "Example task using the config_template module" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:143 msgid "" "In this task the ``test.ini.j2`` file is a template which will be rendered " "and written to disk at ``/tmp/test.ini``. The **config_overrides** entry is " "a dictionary (hash) which allows a deployer to set arbitrary data as " "overrides to be written into the configuration file at run time. The " "**config_type** entry specifies the type of configuration file the module " "will be interacting with; available options are \"yaml\", \"json\", and " "\"ini\"." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:160 msgid "Here is an example override dictionary (hash)" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:169 msgid "And here is the template file:" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:177 msgid "The rendered file on disk, namely ``/tmp/test.ini`` looks like this:" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:189 msgid "Discovering available overrides" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:191 msgid "" "All of these options can be specified in any way that suits your deployment. " "In terms of ease of use and flexibility it's recommended that you define " "your overrides in a user variable file such as ``/etc/openstack_deploy/" "user_variables.yml``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:196 msgid "The list of overrides available may be found by executing:" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:207 msgid "" "Possible additional overrides can be found in the \"Tunable Section\" of " "each role's ``main.yml`` file, such as ``/etc/ansible/roles/role_name/" "defaults/main.yml``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:212 msgid "Overriding OpenStack configuration defaults" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:214 msgid "" "OpenStack has many configuration options available in ``.conf`` files (in a " "standard ``INI`` file format), policy files (in a standard ``JSON`` format) " "and ``YAML`` files, and can therefore use the ``config_template`` module " "described above." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:219 msgid "" "OpenStack-Ansible enables you to reference any options in the `OpenStack " "Configuration Reference`_ through the use of a simple set of configuration " "entries in the ``/etc/openstack_deploy/user_variables.yml``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:226 msgid "Overriding .conf files" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:228 msgid "" "Most often, overrides are implemented for the ``.conf`` files (for " "example, ``nova.conf``). These files use a standard INI file format." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:231 msgid "" "For example, you might want to add the following parameters to the ``nova." "conf`` file:" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:247 #: ../../source/reference/configuration/using-overrides.rst:324 #: ../../source/reference/configuration/using-overrides.rst:374 msgid "" "To do this, you use the following configuration entry in the ``/etc/" "openstack_deploy/user_variables.yml`` file:" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:264 msgid "" "The general format for the variable names used for overrides is " "``___overrides``. For example, the " "variable name used in these examples to add parameters to the ``nova.conf`` " "file is ``nova_nova_conf_overrides``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:269 msgid "" "The same way you can apply overrides to the uwsgi services. For example:" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:279 msgid "" "Some roles, like uwsgi, are used for lot of roles, and have \"special\" " "overrides, (like `uwsgi_ini_overrides`) which can be defined to impact all " "services which are using uwsgi. These variables are \"special\" as they will " "have precedence over role defined `*_uwsgi_ini_overrides`." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:284 msgid "" "You can also apply overrides on a per-host basis with the following " "configuration in the ``/etc/openstack_deploy/openstack_user_config.yml`` " "file:" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:304 msgid "" "Use this method for any files with the ``INI`` format for in OpenStack " "projects deployed in OpenStack-Ansible." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:308 msgid "Overriding .json files" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:310 msgid "" "To implement access controls that are different from the ones in a standard " "OpenStack environment, you can adjust the default policies applied by " "services. Policy files are in a ``JSON`` format." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:314 msgid "" "For example, you might want to add the following policy in the ``policy." "json`` file for the Identity service (keystone):" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:335 msgid "" "The general format for the variable names used for overrides is " "``_policy_overrides``. For example, the variable name used in this " "example to add a policy to the Identity service (keystone) ``policy.json`` " "file is ``keystone_policy_overrides``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:340 msgid "" "Use this method for any files with the ``JSON`` format in OpenStack projects " "deployed in OpenStack-Ansible." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:343 msgid "" "To assist you in finding the appropriate variable name to use for overrides, " "the general format for the variable name is ``_policy_overrides``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:348 msgid "Overriding .yml files" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:350 msgid "" "You can override ``.yml`` file values by supplying replacement YAML content." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:354 msgid "" "All default YAML file content is completely overwritten by the overrides, so " "the entire YAML source (both the existing content and your changes) must be " "provided." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:358 msgid "" "For example, you might want to define a meter exclusion for all hardware " "items in the default content of the ``pipeline.yml`` file for the Telemetry " "service (ceilometer):" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:392 msgid "" "The general format for the variable names used for overrides is " "``___overrides``. For example, the " "variable name used in this example to define a meter exclusion in the " "``pipeline.yml`` file for the Telemetry service (ceilometer) is " "``ceilometer_pipeline_yaml_overrides``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:398 msgid "Overriding OpenStack upper constraints" msgstr "" #: ../../source/reference/configuration/using-overrides.rst:400 msgid "" "Each OpenStack release uses an ``upper-constraints.txt`` file to define the " "maximum permitted version of each Python package. In some cases it may be " "necessary to override this file, for example when your local deployment " "needs to take advantage of a bug fix. Care should be taken when modifying " "this file as OpenStack services may not have been tested against more recent " "package versions." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:407 msgid "" "To override the upper constraints for a deployment, clone the OpenStack " "requirements git repository, either storing it as a fork at a URL of your " "choice, or within the local filesystem of the host you are using to deploy " "OpenStack Ansible from. Once cloned, switch to the branch which matches the " "name of your deployed OpenStack version, and modify the upper constraints as " "required." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:414 msgid "" "Next, edit your ``/etc/openstack_deploy/user_variables.yml`` file to " "indicate the path to the requirements git repository, and the git hash of " "the commit containing your changes using the ``requirements_git_repo`` and " "``requirements_git_install_branch`` variables. When using the local " "filesystem, the ``requirements_git_repo`` should start with ``file://``." msgstr "" #: ../../source/reference/configuration/using-overrides.rst:420 msgid "" "Finally, run the ``repo-install.yml`` playbook to upload these modified " "constraints to your repo host(s)." msgstr "" #: ../../source/reference/conventions.rst:3 msgid "Conventions" msgstr "" #: ../../source/reference/conventions.rst:5 msgid "" "To avoid extra configuration, a series of conventions are set into code." msgstr "" #: ../../source/reference/conventions.rst:8 msgid "Default folders locations" msgstr "" #: ../../source/reference/conventions.rst:11 msgid "Ansible roles" msgstr "" #: ../../source/reference/conventions.rst:13 msgid "The ansible roles are stored under ``/etc/ansible/roles``." msgstr "" #: ../../source/reference/conventions.rst:16 msgid "OpenStack-Ansible directory checkout" msgstr "" #: ../../source/reference/conventions.rst:18 msgid "The code is generally located into ``/opt/openstack-ansible``." msgstr "" #: ../../source/reference/conventions.rst:21 msgid "OpenStack-Ansible wrapper" msgstr "" #: ../../source/reference/conventions.rst:23 msgid "" "Our ``openstack-ansible`` cli is located in ``/usr/local/bin/openstack-" "ansible``. It sources an environment variable file located in: ``/usr/local/" "bin/openstack-ansible.rc``." msgstr "" #: ../../source/reference/conventions.rst:28 msgid "Userspace configurations" msgstr "" #: ../../source/reference/conventions.rst:30 msgid "" "All the userspace configurations are expected to be in ``/etc/" "openstack_deploy/``." msgstr "" #: ../../source/reference/conventions.rst:34 msgid "Ansible configuration" msgstr "" #: ../../source/reference/conventions.rst:37 msgid "Ansible.cfg" msgstr "" #: ../../source/reference/conventions.rst:39 msgid "" "There is no ``ansible.cfg`` provided with OpenStack-Ansible. Environment " "variables are used to alter the default Ansible behavior if necessary." msgstr "" #: ../../source/reference/conventions.rst:44 msgid "Ansible roles fetching" msgstr "" #: ../../source/reference/conventions.rst:46 msgid "" "Any roles defined in ``openstack-ansible/ansible-role-requirements.yml`` " "will be installed by the ``openstack-ansible/scripts/bootstrap-ansible.sh`` " "script, and fetched into the ansible roles folder." msgstr "" #: ../../source/reference/conventions.rst:52 msgid "Inventory conventions" msgstr "" #: ../../source/reference/conventions.rst:54 msgid "Please confer to the inventory section of this reference." msgstr "" #: ../../source/reference/index.rst:3 msgid "OpenStack-Ansible Reference" msgstr "" #: ../../source/reference/index.rst:5 msgid "" "This chapter contains all the extra reference information to deploy, " "configure, or upgrade an OpenStack-Ansible cloud." msgstr "" #: ../../source/reference/index.rst:8 msgid "" "For information on how to deploy your OpenStack-Ansible cloud, refer to the :" "deploy_guide:`Deployment Guide ` for step-by-step instructions " "on how to deploy the OpenStack packages and dependencies on your cloud using " "OpenStack-Ansible." msgstr "" #: ../../source/reference/index.rst:13 msgid "For user guides, see the :dev_docs:`User Guide `." msgstr "" #: ../../source/reference/index.rst:15 msgid "" "For information on how to manage and operate OpenStack-Ansible, see the see " "the :dev_docs:`Operations Guide `." msgstr "" #: ../../source/reference/index.rst:18 msgid "" "For information on how to contribute, extend or develop OpenStack-Ansible, " "see the :dev_docs:`Contributors Guide `." msgstr "" #: ../../source/reference/inventory/advanced-topics.rst:2 msgid "Advanced inventory topics" msgstr "" #: ../../source/reference/inventory/advanced-topics.rst:5 msgid "Changing the base environment directory" msgstr "" #: ../../source/reference/inventory/advanced-topics.rst:7 msgid "" "The ``--environment/-e`` argument will take the path to a directory " "containing an ``env.d`` directory. This defaults to ``inventory/`` in the " "OpenStack-Ansible codebase." msgstr "" #: ../../source/reference/inventory/advanced-topics.rst:11 msgid "" "Contents of this directory are populated into the environment *before* the " "``env.d`` found in the directory specified by ``--config``." msgstr "" #: ../../source/reference/inventory/advanced-topics.rst:15 msgid "Dynamic Inventory API documentation" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:4 msgid "Configuring the inventory" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:6 msgid "" "In this chapter, you can find the information on how to configure the " "openstack-ansible dynamic inventory to your needs." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:12 msgid "" "Common OpenStack services and their configuration are defined by OpenStack-" "Ansible in the ``/etc/openstack_deploy/openstack_user_config.yml`` settings " "file." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:16 msgid "" "Additional services should be defined with a YAML file in ``/etc/" "openstack_deploy/conf.d``, in order to manage file size." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:19 msgid "" "The ``/etc/openstack_deploy/env.d`` directory sources all YAML files into " "the deployed environment, allowing a deployer to define additional group " "mappings. This directory is used to extend the environment skeleton, or " "modify the defaults defined in the ``inventory/env.d`` directory." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:24 msgid "" "To understand how the dynamic inventory works, see :ref:`inventory-in-depth`." "" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:29 #: ../../source/reference/inventory/manage-inventory.rst:6 msgid "" "Never edit or delete the file ``/etc/openstack_deploy/openstack_inventory." "json``. This can lead to problems with the inventory: existng hosts and " "containers will be unmanaged and new ones will be generated instead, " "breaking your existing deployment." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:35 msgid "Configuration constraints" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:38 msgid "Group memberships" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:40 msgid "When adding groups, keep the following in mind:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:42 msgid "A group can contain hosts" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:43 msgid "A group can contain child groups" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:45 msgid "However, groups cannot contain child groups and hosts." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:48 msgid "The lxc_hosts Group" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:50 msgid "" "When the dynamic inventory script creates a container name, the host on " "which the container resides is added to the ``lxc_hosts`` inventory group." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:53 msgid "" "Using this name for a group in the configuration will result in a runtime " "error." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:57 msgid "Deploying directly on hosts" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:59 msgid "" "To deploy a component directly on the host instead of within a container, " "set the ``is_metal`` property to ``true`` for the container group in the " "``container_skel`` section in the appropriate file." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:63 msgid "" "The use of ``container_vars`` and mapping from container groups to host " "groups is the same for a service deployed directly onto the host." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:66 msgid "" "You can also use the ``no_containers`` option to specify a host that will " "have all services deployed on metal inside of it." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:71 msgid "" "The ``cinder-volume`` component is deployed directly on the host by default. " "See the ``env.d/cinder.yml`` file for this example." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:75 msgid "Example: Running all controllers on metal" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:76 msgid "" "For example, if you'd like to run all your controllers on metal, you would " "have the following inside your ``openstack_user_config.yml``." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:93 msgid "Example: Running galera on dedicated hosts" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:95 msgid "" "For example, to run Galera directly on dedicated hosts, you would perform " "the following steps:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:98 msgid "" "Modify the ``container_skel`` section of the ``env.d/galera.yml`` file. For " "example:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:114 msgid "" "To deploy within containers on these dedicated hosts, omit the ``is_metal: " "true`` property." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:117 msgid "" "Assign the ``db_containers`` container group (from the preceding step) to a " "host group by providing a ``physical_skel`` section for the host group in a " "new or existing file, such as ``env.d/galera.yml``. For example:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:132 msgid "" "Define the host group (``db_hosts``) in a ``conf.d/`` file (such as ``galera." "yml``). For example:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:147 msgid "" "Each of the custom group names in this example (``db_containers`` and " "``db_hosts``) are arbitrary. Choose your own group names, but ensure the " "references are consistent among all relevant files." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:154 msgid "Adding virtual nest groups" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:156 msgid "" "If you want to create a custom group for arbitrary grouping of hosts and " "containers within these hosts but skip the generation of any new containers, " "you should use ``is_nest`` property under container_skel and skip defining " "``belongs_to`` structure. ``is_nest`` property will add host-containers as " "children to such a group." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:163 msgid "Example: Defining Availability Zones" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:165 msgid "" "A good example of how ``is_nest`` property can be used is describing " "Availability Zones. As when operating multiple AZs it's handy to define AZ-" "specific variables, like AZ name, for all hosts in this AZ. And leveraging " "group_vars is best way of ensuring that all hosts that belong to same AZ " "have same configuration applied." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:171 msgid "" "Let's assume you have 3 controllers and each of them is placed in different " "Availability Zones. There is also a compute node in each Availability Zone. " "And we want each host or container that is placed physically in a specific " "AZ be part of it's own group (ie azN_all)" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:176 msgid "In order to achieve that we need:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:178 msgid "" "Define host groups in conf.d or openstack_user_config.yml to assign hosts " "accordingly to their Availability Zones:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:229 msgid "" "Create ``env.d/az.yml`` file that will leverage ``is_nest`` property and " "allow all infra containers to be part of the AZ group as well" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:267 msgid "" "Now you can leverage group_vars file to apply a variable to all containers " "and bare metal hosts in AZ. For example ``/etc/openstack_deploy/group_vars/" "az1_all.yml``:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:279 msgid "Deploying 0 (or more than one) of component type per host" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:281 msgid "" "When OpenStack-Ansible generates its dynamic inventory, the affinity setting " "determines how many containers of a similar type are deployed on a single " "physical host." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:285 msgid "" "Using ``shared-infra_hosts`` as an example, consider this " "``openstack_user_config.yml`` configuration:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:298 msgid "" "Three hosts are assigned to the `shared-infra_hosts` group, OpenStack-" "Ansible ensures that each host runs a single database container, a single " "Memcached container, and a single RabbitMQ container. Each host has an " "affinity of 1 by default, which means that each host runs one of each " "container type." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:304 msgid "" "If you are deploying a stand-alone Object Storage (swift) environment, you " "can skip the deployment of RabbitMQ. If you use this configuration, your " "``openstack_user_config.yml`` file would look as follows:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:324 msgid "" "This configuration deploys a Memcached container and a database container on " "each host, but no RabbitMQ containers." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:328 msgid "Omit a service or component from the deployment" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:330 msgid "" "To omit a component from a deployment, you can use one of several options:" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:332 msgid "" "Remove the ``physical_skel`` link between the container group and the host " "group by deleting the related file located in the ``env.d/`` directory." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:335 msgid "" "Do not run the playbook that installs the component. Unless you specify the " "component to run directly on a host by using the ``is_metal`` property, a " "container is created for this component." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:338 msgid "" "Adjust the :ref:`affinity` to 0 for the host group. Similar to the second " "option listed here, Unless you specify the component to run directly on a " "host by using the ``is_metal`` property, a container is created for this " "component." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:345 msgid "Having SSH network different from OpenStack Management network" msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:347 msgid "" "In some environments SSH network that is used to access nodes from deploy " "host and management network are different. In this case it's important that " "services were listening on correct network while ensure that Ansible use SSH " "network for accessing managed hosts. In these cases you can define " "``management_ip`` key while defining hosts in your ``openstack_user_config." "yml`` file." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:354 msgid "" "``management_ip`` will be used as ``management_address`` for the node, while " "``ip`` will be used as ``ansible_host`` for accessing node by SSH." msgstr "" #: ../../source/reference/inventory/configure-inventory.rst:357 msgid "Example:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:2 msgid "Generating the Inventory" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:4 msgid "" "The script that creates the inventory is located at ``inventory/" "dynamic_inventory.py`` and installed into the ansible-runtime virtualenv as " "``openstack-ansible-inventory``." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:8 msgid "" "This section explains how ansible runs the inventory, and how you can run it " "manually to see its behavior." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:12 msgid "Executing the dynamic_inventory.py script manually" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:14 msgid "" "When running an Ansible command (such as ``ansible``, ``ansible-playbook`` " "or ``openstack-ansible``) Ansible automatically executes the " "``dynamic_inventory.py`` script and use its output as inventory." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:19 msgid "Run the following command:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:26 msgid "" "Dynamic inventory script is also installed inside virtualenv as a script. So " "alternatively you can run following:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:34 msgid "" "This invocation is useful when testing changes to the dynamic inventory " "script." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:37 msgid "Inputs" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:39 msgid "" "The ``dynamic_inventory.py`` takes the ``--config`` argument for the " "directory holding configuration from which to create the inventory. If not " "specified, the default is ``/etc/openstack_deploy/``." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:43 msgid "" "In addition to this argument, the base environment skeleton is provided in " "the ``inventory/env.d`` directory of the OpenStack-Ansible codebase." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:46 msgid "" "Should an ``env.d`` directory be found in the directory specified by ``--" "config``, its contents will be added to the base environment, overriding any " "previous contents in the event of conflicts." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:52 msgid "" "In all versions prior to |previous_release_formal_name|, this argument was " "``--file``." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:54 msgid "The following file must be present in the configuration directory:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:56 msgid "``openstack_user_config.yml``" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:58 msgid "" "Additionally, the configuration or environment could be spread between two " "additional sub-directories:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:61 msgid "``conf.d``" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:62 msgid "``env.d`` (for environment customization)" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:64 msgid "The dynamic inventory script does the following:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:66 msgid "Generates the names of each container that runs a service" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:67 msgid "Creates container and IP address mappings" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:68 msgid "Assigns containers to physical hosts" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:70 msgid "" "As an example, consider the following excerpt from ``openstack_user_config." "yml``:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:83 msgid "" "The ``identity_hosts`` dictionary defines an Ansible inventory group named " "``identity_hosts`` containing the three infra hosts. The configuration file " "``inventory/env.d/keystone.yml`` defines additional Ansible inventory groups " "for the containers that are deployed onto the three hosts named with the " "prefix *infra*." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:89 msgid "" "Note that any services marked with ``is_metal: true`` will run on the " "allocated physical host and not in a container. For an example of ``is_metal:" " true`` being used refer to ``inventory/env.d/cinder.yml`` in the " "``container_skel`` section." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:94 msgid "For more details, see :ref:`configuring-inventory`." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:97 msgid "Outputs" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:99 msgid "" "Once executed, the script will output an ``openstack_inventory.json`` file " "into the directory specified with the ``--config`` argument. This is used as " "the source of truth for repeated runs." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:105 msgid "" "The ``openstack_inventory.json`` file is the source of truth for the " "environment. Deleting this in a production environment means that the UUID " "portion of container names will be regenerated, which then results in new " "containers being created. Containers generated under the previous version " "will no longer be recognized by Ansible, even if reachable via SSH." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:111 msgid "" "The same JSON structure is printed to stdout, which is consumed by Ansible " "as the inventory for the playbooks." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:115 msgid "Checking inventory configuration for errors" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:117 msgid "" "Using the ``--check`` flag when running ``dynamic_inventory.py`` will run " "the inventory build process and look for known errors, but not write any " "files to disk." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:121 msgid "" "If any groups defined in the ``openstack_user_config.yml`` or ``conf.d`` " "files are not found in the environment, a warning will be raised." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:124 msgid "" "This check does not do YAML syntax validation, though it will fail if there " "are unparseable errors." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:128 msgid "Writing debug logs" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:130 msgid "" "The ``--debug/-d`` parameter allows writing of a detailed log file for " "debugging the inventory script's behavior. The output is written to " "``inventory.log`` in the current working directory." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:134 msgid "The ``inventory.log`` file is appended to, not overwritten." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:136 msgid "Like ``--check``, this flag is not invoked when running from ansible." msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:140 msgid "Running with tox" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:142 msgid "" "In some cases you might want to generate inventory on operator local " "machines after altering openstack_user_config.yml or env.d/conf.d files. " "Given that you already have ``openstack_deploy`` directory on such machine, " "you can create tox.ini file in that directory with following content:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:166 msgid "Then you can run a command to generate inventory using tox:" msgstr "" #: ../../source/reference/inventory/generate-inventory.rst:172 msgid "" "As a result you will get your openstack_user_config.json updated. You can " "use this method also to verify validity of the inventory." msgstr "" #: ../../source/reference/inventory/inventory.rst:3 msgid "Inventory" msgstr "" #: ../../source/reference/inventory/inventory.rst:5 msgid "" "OpenStack-Ansible uses an included script to generate the inventory of hosts " "and containers within the environment. This script is called by Ansible " "through its `dynamic inventory functionality `_." msgstr "" #: ../../source/reference/inventory/inventory.rst:9 msgid "" "In this section, you will find documentation relevant to the inventory for " "OpenStack-Ansible." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:2 msgid "Inspecting and manipulating the inventory" msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:11 msgid "" "The file ``scripts/inventory-manage.py`` is used to produce human readable " "output based on the ``/etc/openstack_deploy/openstack_inventory.json`` file." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:14 msgid "" "The same script can be used to safely remove hosts from the inventory, " "export the inventory based on hosts, and clear IP addresses from containers " "within the inventory files." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:18 msgid "" "Operations taken by this script only affect the ``/etc/opentstack_deploy/" "openstack_inventory.json`` file; any new or removed information must be set " "by running playbooks." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:23 msgid "Viewing the inventory" msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:25 msgid "" "The ``/etc/openstack_deploy/openstack_inventory.json`` file is read by " "default. An alternative file can be specified with ``--file``." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:28 msgid "A list of all hosts can be seen with the ``--list-host/-l`` argument" msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:30 msgid "" "To see a listing of hosts and containers by their group, use ``--list-groups/" "-g``." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:33 msgid "To see all of the containers, use ``--list-containers/-G``." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:36 msgid "Removing a host" msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:38 msgid "A host can be removed with the ``--remove-item/-r`` parameter." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:40 msgid "Use the host's name as an argument." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:45 msgid "Removing a group" msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:47 msgid "A host group can be removed with the ``--remove-group/-d`` parameter." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:49 msgid "" "Use the groups's name as an argument. You can repeat argument multiple times " "to remove several groups at once." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:54 msgid "Exporting host information" msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:56 msgid "" "Information on a per-host basis can be obtained with the ``--export/-e`` " "parameter." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:59 msgid "This JSON output has two top-level keys: ``hosts`` and ``all``." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:61 msgid "" "``hosts`` contains a map of a host's name to its variable and group data." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:63 msgid "" "``all`` contains global network information such as the load balancer IPs " "and provider network metadata." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:67 msgid "Clearing existing container IP addresses" msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:69 msgid "" "The ``--clear-ips`` parameter can be used to remove all container IP address " "information from the ``openstack_inventory.json`` file. Baremetal hosts will " "not be changed." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:73 msgid "" "This will *not* change the LXC configuration until the associated playbooks " "are run and the containers restarted, which will result in API downtime." msgstr "" #: ../../source/reference/inventory/manage-inventory.rst:76 msgid "" "Any changes to the containers must also be reflected in the deployment's " "load balancer." msgstr "" #: ../../source/reference/inventory/openstack-user-config-reference.rst:4 msgid "openstack_user_config settings reference" msgstr "" #: ../../source/reference/inventory/openstack-user-config-reference.rst:6 msgid "" "The ``openstack_user_config.yml.example`` file is heavily commented with the " "details of how to do more advanced container networking configuration. The " "contents of the file are shown here for reference." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:4 msgid "Understanding the inventory" msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:6 msgid "" "The default layout of containers and services in OpenStack-Ansible (OSA) is " "determined by the ``/etc/openstack_deploy/openstack_user_config.yml`` file " "and the contents of both the ``/etc/openstack_deploy/conf.d/`` and ``/etc/" "openstack_deploy/env.d/`` directories. You use these sources to define the " "*group* mappings that the playbooks use to target hosts and containers for " "roles used in the deploy." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:13 msgid "" "You define host groups, which gather the target hosts into *inventory " "groups*, through the ``/etc/openstack_deploy/openstack_user_config.yml`` " "file and the contents of the ``/etc/openstack_deploy/conf.d/`` directory." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:17 msgid "" "You define *container groups*, which can map from the service components to " "be deployed up to host groups, through files in the ``/etc/openstack_deploy/" "env.d/`` directory." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:21 msgid "" "To customize the layout of the components for your deployment, modify the " "host groups and container groups appropriately before running the " "installation playbooks." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:28 msgid "Understanding host groups (conf.d structure)" msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:30 msgid "" "As part of the initial configuration, each target host appears either in the " "``/etc/openstack_deploy/openstack_user_config.yml`` file or in files within " "the ``/etc/openstack_deploy/conf.d/`` directory. The format used for files " "in the ``conf.d/`` directory is identical to the syntax used in the " "``openstack_user_config.yml`` file." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:36 msgid "" "In these files, the target hosts are listed under one or more headings, such " "as ``shared-infra_hosts`` or ``storage_hosts``, which serve as Ansible group " "mappings. These groups map to the physical hosts." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:41 msgid "" "The ``haproxy.yml.example`` file in the ``conf.d/`` directory provides a " "simple example of defining a host group (``load_balancer_hosts``) with two " "hosts (``infra1`` and ``infra2``)." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:45 msgid "" "The ``swift.yml.example`` file provides a more complex example. Here, host " "variables for a target host are specified by using the ``container_vars`` " "key. OpenStack-Ansible applies all entries under this key as host-specific " "variables to any component containers on the specific host." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:52 msgid "" "To manage file size, we recommend that you define new inventory groups, " "particularly for new services, by using a new file in the ``conf.d/`` " "directory." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:59 msgid "Understanding container groups (env.d structure)" msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:61 msgid "" "Additional group mappings are located within files in the ``/etc/" "openstack_deploy/env.d/`` directory. These groups are treated as virtual " "mappings from the host groups (described above) onto the container groups, " "that define where each service deploys. By reviewing files within the ``env." "d/`` directory, you can begin to see the nesting of groups represented in " "the default layout." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:68 msgid "" "For example, the ``shared-infra.yml`` file defines a container group, " "``shared-infra_containers``, as a subset of the ``all_containers`` inventory " "group. The ``shared- infra_containers`` container group is mapped to the " "``shared-infra_hosts`` host group. All of the service components in the " "``shared-infra_containers`` container group are deployed to each target host " "in the ``shared-infra_hosts host`` group." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:75 msgid "" "Within a ``physical_skel`` section, the OpenStack-Ansible dynamic inventory " "expects to find a pair of keys. The first key maps to items in the " "``container_skel`` section, and the second key maps to the target host " "groups (described above) that are responsible for hosting the service " "component." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:80 msgid "" "To continue the example, the ``memcache.yml`` file defines the " "``memcache_container`` container group. This group is a subset of the " "``shared-infra_containers`` group, which is itself a subset of the " "``all_containers`` inventory group." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:87 msgid "" "The ``all_containers`` group is automatically defined by OpenStack-Ansible. " "Any service component managed by OpenStack-Ansible maps to a subset of the " "``all_containers`` inventory group, directly or indirectly through another " "intermediate container group." msgstr "" #: ../../source/reference/inventory/understanding-inventory.rst:92 msgid "" "The default layout does not rely exclusively on groups being subsets of " "other groups. The ``memcache`` component group is part of the " "``memcache_container`` group, as well as the ``memcache_all`` group and also " "contains a ``memcached`` component group. If you review the ``playbooks/" "memcached-install.yml`` playbook, you see that the playbook applies to hosts " "in the ``memcached`` group. Other services might have more complex " "deployment needs. They define and consume inventory container groups " "differently. Mapping components to several groups in this way allows " "flexible targeting of roles and tasks." msgstr "" #: ../../source/reference/releases.rst:5 msgid "Releases" msgstr "" #: ../../source/reference/releases.rst:8 msgid "What is the OSA release model" msgstr "" #: ../../source/reference/releases.rst:9 msgid "" "OpenStack-Ansible (OSA) uses the 'cycle-trailing' release model as specified " "in the OpenStack `release model reference_`." msgstr "" #: ../../source/reference/releases.rst:15 msgid "How are release tags decided?" msgstr "" #: ../../source/reference/releases.rst:16 msgid "" "In order to ensure a common understanding of what release versions mean, we " "use `Semantic Versioning 2.0.0_` for versioning as a basis. The exception to " "the rule is for milestone releases during a development cycle, where " "releases are tagged ``.0.0.0b`` where ```` is the " "next major release number, and ```` is the milestone number." msgstr "" #: ../../source/reference/releases.rst:22 msgid "" "The OpenStack series names are alphabetical, with each letter matched to a " "number (eg: Austin = 1, Bexar = 2, Newton = 14, Pike = 16, etc). OSA adopted " "the same ```` release numbering as the Nova project to match the " "overall OpenStack series version numbering." msgstr "" #: ../../source/reference/releases.rst:30 msgid "How frequently does OSA release?" msgstr "" #: ../../source/reference/releases.rst:32 msgid "" "Major releases are done every six months according to the `OpenStack release " "schedule_`. Each major release is consistent with an OpenStack series." msgstr "" #: ../../source/reference/releases.rst:35 msgid "" "Minor/patch releases are requested for stable branches on the second and " "last Friday of every month. The releases are typically completed within a " "few days of the request." msgstr "" #: ../../source/reference/releases.rst:42 msgid "What version of OpenStack is deployed by OSA?" msgstr "" #: ../../source/reference/releases.rst:44 msgid "" "For each OSA release, the OpenStack version that is deployed is set to a " "specific OpenStack `git SHA-1 hash_` (SHA). These are updated after every " "OSA release. The intent is to ensure that OSA users are able to enjoy an " "updated OpenStack environment with smaller increments of change than the " "typical upstream service releases allow for as they are usually very " "infrequent." msgstr "" #: ../../source/reference/releases.rst:51 msgid "" "This does mean that a stable OSA deployment will include a version of a " "service (eg: nova-17.0.3dev4) which does not match a tag exactly as you may " "expect (eg: nova-17.0.3)." msgstr "" #: ../../source/reference/releases.rst:55 msgid "" "If you wish to change the SHA to a specific SHA/tag/branch, or wish to use " "your own fork of an OpenStack service, please see the section titled :ref:" "`override_openstack_sources` in the user guide." msgstr "" #: ../../source/reference/releases.rst:62 msgid "When does a patch to an OSA role get into a release?" msgstr "" #: ../../source/reference/releases.rst:64 msgid "" "For each OSA release, the Ansible roles that form that release are set to a " "specific `git SHA-1 hash_` (SHA). These are updated after every OSA release." msgstr "" #: ../../source/reference/releases.rst:67 msgid "" "OSA frequently does pro-active bugfix backports. In order to reduce the risk " "of these backports introducing any destabilization, OSA implements a 'soak' " "period for any patches implemented in the stable branches for roles, but " "also provides for circumventing this in exceptional circumstances." msgstr "" #: ../../source/reference/releases.rst:72 msgid "" "A patch merged into a role is immediately tested by other role tests, " "ensuring that any major breaking change is caught. Once a minor/patch " "release is requested, the integrated build receives a 'SHA bump' patch to " "update the integrated build to using the latest available roles including " "that new patch. This new set is available for testing to anyone wanting to " "use the head of the stable branch, and is tested in periodic tests until the " "next release. In total, that means that the cycle time for a patch from " "merge to release is anywhere from two weeks to one month." msgstr "" #: ../../source/reference/releases.rst:81 msgid "" "If there is a requirement to rush a role patch into the next release, then " "anyone may propose a change to the ``ansible-role-requirements.yml`` file in " "the ``openstack/openstack-ansible`` repository with the appropriate " "justification." msgstr "" #: ../../source/reference/releases.rst:86 msgid "" "We believe that this approach brings a balance of both reasonable stability, " "while still being able to do pro-active backports." msgstr "" #: ../../source/reference/releases.rst:89 msgid "" "The only exception to this rule is for the ``master`` branch, which " "intentionally consumes the ``master`` branch from all roles between releases " "so that any changes are immediately integration tested." msgstr ""