#, fuzzy msgid "" msgstr "" "Project-Id-Version: openstack-ansible 30.0.0.0b2.dev28\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2024-11-21 15:16+0000\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../../source/user/aio/quickstart.rst:5 msgid "Quickstart: AIO" msgstr "" #: ../../source/user/aio/quickstart.rst:7 msgid "" "All-in-one (AIO) builds are a great way to perform an OpenStack-Ansible " "build for:" msgstr "" #: ../../source/user/aio/quickstart.rst:10 msgid "a development environment" msgstr "" #: ../../source/user/aio/quickstart.rst:11 msgid "an overview of how all of the OpenStack services fit together" msgstr "" #: ../../source/user/aio/quickstart.rst:12 msgid "a simple lab deployment" msgstr "" #: ../../source/user/aio/quickstart.rst:14 msgid "" "Although AIO builds aren't recommended for large production deployments, " "they're great for smaller proof-of-concept deployments." msgstr "" #: ../../source/user/aio/quickstart.rst:17 msgid "Absolute minimum server resources (currently used for gate checks):" msgstr "" #: ../../source/user/aio/quickstart.rst:19 msgid "8 vCPU's" msgstr "" #: ../../source/user/aio/quickstart.rst:20 msgid "50GB free disk space on the root partition" msgstr "" #: ../../source/user/aio/quickstart.rst:21 msgid "8GB RAM" msgstr "" #: ../../source/user/aio/quickstart.rst:23 msgid "Recommended server resources:" msgstr "" #: ../../source/user/aio/quickstart.rst:25 msgid "CPU/motherboard that supports `hardware-assisted virtualization`_" msgstr "" #: ../../source/user/aio/quickstart.rst:26 msgid "8 CPU Cores" msgstr "" #: ../../source/user/aio/quickstart.rst:27 msgid "" "80GB free disk space on the root partition, or 60GB+ on a blank secondary " "disk. Using a secondary disk requires the use of the " "``bootstrap_host_data_disk_device`` parameter. Please see `Building an AIO`_ " "for more details." msgstr "" #: ../../source/user/aio/quickstart.rst:31 msgid "16GB RAM" msgstr "" #: ../../source/user/aio/quickstart.rst:33 msgid "" "It is `possible` to perform AIO builds within a virtual machine for " "demonstration and evaluation, but your virtual machines will perform poorly " "unless nested virtualization is available. For production workloads, " "multiple nodes for specific roles are recommended." msgstr "" #: ../../source/user/aio/quickstart.rst:42 msgid "Building an AIO" msgstr "" #: ../../source/user/aio/quickstart.rst:45 msgid "Overview" msgstr "" #: ../../source/user/aio/quickstart.rst:47 msgid "" "There are three steps to running an AIO build, with an optional first step " "should you need to customize your build:" msgstr "" #: ../../source/user/aio/quickstart.rst:50 #: ../../source/user/aio/quickstart.rst:56 msgid "Prepare the host" msgstr "" #: ../../source/user/aio/quickstart.rst:51 #: ../../source/user/aio/quickstart.rst:93 msgid "Bootstrap Ansible and the required roles" msgstr "" #: ../../source/user/aio/quickstart.rst:52 #: ../../source/user/aio/quickstart.rst:161 msgid "Bootstrap the AIO configuration" msgstr "" #: ../../source/user/aio/quickstart.rst:53 #: ../../source/user/aio/quickstart.rst:250 msgid "Run playbooks" msgstr "" #: ../../source/user/aio/quickstart.rst:58 msgid "" "When building an AIO on a new server, it is recommended that all system " "packages are upgraded and then reboot into the new kernel:" msgstr "" #: ../../source/user/aio/quickstart.rst:61 msgid "Execute the following commands and scripts as the root user." msgstr "" #: ../../source/user/aio/quickstart.rst:81 msgid "" "Before rebooting, in ``/etc/sysconfig/selinux``, make sure that ``SELINUX=" "enforcing`` is changed to ``SELINUX=disabled``. SELinux enabled is not " "currently supported in OpenStack-Ansible for CentOS/Rocky/RHEL due to a lack " "of maintainers for the feature." msgstr "" #: ../../source/user/aio/quickstart.rst:89 msgid "" "If you are installing with limited connectivity, please review :ref:" "`Installing with limited connectivity ` before " "proceeding." msgstr "" #: ../../source/user/aio/quickstart.rst:95 msgid "" "Start by cloning the OpenStack-Ansible repository and changing into the " "repository root directory:" msgstr "" #: ../../source/user/aio/quickstart.rst:104 msgid "" "Next switch the applicable branch/tag to be deployed from. Note that " "deploying from the head of a branch may result in an unstable build due to " "changes in flight and upstream OpenStack changes. For a test (for example, " "not a development) build it is usually best to checkout the latest tagged " "version." msgstr "" #: ../../source/user/aio/quickstart.rst:123 msgid "" "The |current_release_formal_name| release is only compatible with Debian 12 " "(bookworm), Ubuntu 22.04 (Jammy Jellyfish), Ubuntu 24.04 (Noble Numbat), " "CentOS 9 Stream, and derivitives of CentOS Stream/RHEL such as Rocky Linux." msgstr "" #: ../../source/user/aio/quickstart.rst:128 msgid "" "The next step is to bootstrap Ansible and the Ansible roles for the " "development environment." msgstr "" #: ../../source/user/aio/quickstart.rst:131 msgid "Run the following to bootstrap Ansible and the required roles:" msgstr "" #: ../../source/user/aio/quickstart.rst:138 msgid "" "You might encounter an error while running the Ansible bootstrap script when " "building some of the Python extensions (like pycrypto) which says:" msgstr "" #: ../../source/user/aio/quickstart.rst:145 msgid "" "The reason of this failure might be resulting from a noexec mount flag used " "for the filesystem associated with /tmp which you can check by running the " "following command:" msgstr "" #: ../../source/user/aio/quickstart.rst:153 msgid "" "If this is the case you can specify an alternate path which does not have " "this mount option set:" msgstr "" #: ../../source/user/aio/quickstart.rst:163 msgid "" "In order for all the services to run, the host must be prepared with the " "appropriate disks partitioning, packages, network configuration and " "configurations for the OpenStack Deployment." msgstr "" #: ../../source/user/aio/quickstart.rst:167 msgid "" "By default the AIO bootstrap scripts deploy a base set of OpenStack services " "with sensible defaults for the purpose of a gate check, development or " "testing system." msgstr "" #: ../../source/user/aio/quickstart.rst:171 msgid "" "Review the `bootstrap-host role defaults`_ file to see various configuration " "options. Deployers have the option to change how the host is bootstrapped. " "This is useful when you wish the AIO to make use of a secondary data disk, " "or when using this role to bootstrap a multi-node development environment." msgstr "" #: ../../source/user/aio/quickstart.rst:178 msgid "" "The bootstrap script is pre-set to pass the environment variable " "``BOOTSTRAP_OPTS`` as an additional option to the bootstrap process. For " "example, if you wish to set the bootstrap to re-partition a specific " "secondary storage device (``/dev/sdb``), which will erase all of the data on " "the device, then execute:" msgstr "" #: ../../source/user/aio/quickstart.rst:188 msgid "" "Additional options may be implemented by simply concatenating them with a " "space between each set of options, for example:" msgstr "" #: ../../source/user/aio/quickstart.rst:196 msgid "" "If you are installing with limited connectivity, or you don't have default " "route set, you will need to define interface for outgoing connections " "manually" msgstr "" #: ../../source/user/aio/quickstart.rst:203 msgid "" "For the default AIO scenario, the AIO configuration preparation is completed " "by executing:" msgstr "" #: ../../source/user/aio/quickstart.rst:210 msgid "" "To add OpenStack Services over and above the bootstrap-aio default services " "for the applicable scenario, copy the ``conf.d`` files with the ``.aio`` " "file extension into ``/etc/openstack_deploy`` and rename then to ``.yml`` " "files. For example, in order to enable the OpenStack Telemetry services, " "execute the following:" msgstr "" #: ../../source/user/aio/quickstart.rst:222 msgid "" "It is possible to also do this (and change other defaults) during the " "bootstrap script initial execution by changing the SCENARIO environment " "variable before running the script. The key word 'aio' will ensure that a " "basic set of OpenStack services (cinder, glance, horizon, neutron, nova) " "will be deployed. The key words 'lxc' can be used to set the container back-" "end, while the key word 'metal' will deploy all services without containers. " "In order to implement any other services, add the name of the conf.d file " "name without the `.yml.aio` extension into the SCENARIO environment variable." " Each key word should be delimited by an underscore. For example, the " "following will implement an AIO with barbican, cinder, glance, horizon, " "neutron, and nova. It will set the cinder storage back-end to ceph and will " "make use of LXC as the container back-end." msgstr "" #: ../../source/user/aio/quickstart.rst:240 msgid "" "To add any global overrides, over and above the defaults for the applicable " "scenario, edit ``/etc/openstack_deploy/user_variables.yml``. In order to " "understand the various ways that you can override the default behaviour set " "out in the roles, playbook and group variables, see :ref:`user-overrides`." msgstr "" #: ../../source/user/aio/quickstart.rst:245 msgid "" "See the :deploy_guide:`Deployment Guide ` for a more detailed " "break down of how to implement your own configuration rather than to use the " "AIO bootstrap." msgstr "" #: ../../source/user/aio/quickstart.rst:252 msgid "Finally, run the playbooks by executing:" msgstr "" #: ../../source/user/aio/quickstart.rst:260 msgid "" "The installation process will take a while to complete, but here are some " "general estimates:" msgstr "" #: ../../source/user/aio/quickstart.rst:263 msgid "Bare metal systems with SSD storage: ~ 30-50 minutes" msgstr "" #: ../../source/user/aio/quickstart.rst:264 msgid "Virtual machines with SSD storage: ~ 45-60 minutes" msgstr "" #: ../../source/user/aio/quickstart.rst:265 msgid "Systems with traditional hard disks: ~ 90-120 minutes" msgstr "" #: ../../source/user/aio/quickstart.rst:267 msgid "" "Once the playbooks have fully executed, it is possible to experiment with " "various settings changes in ``/etc/openstack_deploy/user_variables.yml`` and " "only run individual playbooks. For example, to run the playbook for the " "Keystone service, execute:" msgstr "" #: ../../source/user/aio/quickstart.rst:278 msgid "Interacting with an AIO" msgstr "" #: ../../source/user/aio/quickstart.rst:280 msgid "" "Once an AIO has been deployed, you most likely want to interact with it. You " "can do this via the web interface or one of the many clients or libraries " "that exist for OpenStack." msgstr "" #: ../../source/user/aio/quickstart.rst:285 msgid "Using a GUI" msgstr "" #: ../../source/user/aio/quickstart.rst:287 msgid "" "The horizon web interface provides a graphical interface for interacting " "with the AIO deployment. By default, the horizon API is available on port " "443 of the host (or port 80, if SSL certificate configuration was disabled). " "As such, to interact with horizon, simply browse to the IP of the host." msgstr "" #: ../../source/user/aio/quickstart.rst:294 msgid "" "If the AIO was deployed in a cloud VM, you may need to configure security " "groups or firewall rules to allow access to the HTTP(S) ports. For example, " "if the AIO was deployed in an OpenStack VM, you can create and apply a " "suitable security group for interacting with horizon like so:" msgstr "" #: ../../source/user/aio/quickstart.rst:309 #: ../../source/user/aio/quickstart.rst:404 msgid "" "A list of service ports can be found in the `OpenStack Install Guide`__." msgstr "" #: ../../source/user/aio/quickstart.rst:313 msgid "" "This will present a login page. By default, OpenStack-Ansible create a user " "called ``admin``. The password will be the value of the " "``keystone_auth_admin_password`` variable. If you did not configure this " "variable, OpenStack-Ansible auto-generates one. You can view the configured " "password in the ``/etc/openstack_deploy/user_secrets.yml`` file." msgstr "" #: ../../source/user/aio/quickstart.rst:326 msgid "Using this username and password combination, log in to horizon." msgstr "" #: ../../source/user/aio/quickstart.rst:329 msgid "Using a client or library" msgstr "" #: ../../source/user/aio/quickstart.rst:331 msgid "" "There are a variety of clients and libraries available for interacting with " "an OpenStack deployment, including as `openstackclient`__, `openstacksdk`__, " "or `gophercloud`__. These are typically configured using either environment " "variables sourced from an ``openrc`` file or the newer ``clouds.yaml`` file." msgstr "" #: ../../source/user/aio/quickstart.rst:340 msgid "" "OpenStack-Ansible provides the ``openstack_openrc`` role for creating these " "configuration files as well as a number of utilities such as " "*openstackclient*. If the AIO deployment using the ``lxc`` scenario (the " "default), these will be availably in the utility container." msgstr "" #: ../../source/user/aio/quickstart.rst:360 msgid "" "Alternatively, if the AIO was deployed using the ``metal`` scenario, these " "files will be available on the host itself." msgstr "" #: ../../source/user/aio/quickstart.rst:371 msgid "" "If you wish to access the AIO deployment from another host - perhaps your " "local workstation - you will need either an ``openrc`` file or ``clouds." "yaml`` file. You can download an ``openrc`` file from horizon: simply click " "the User dropdown in the top-right corner and select *⭳ OpenStack RC file*." msgstr "" #: ../../source/user/aio/quickstart.rst:378 msgid "" "You may be tempted to copy the ``openrc`` or ``clouds.yaml`` files created " "by the ``openstack_openrc`` role. However, these files use the ``internal`` " "`interface`__ by default. This interface use the management network (``172." "29.236.0/22``) , which is not routable from outside the host. If you wish to " "use these files, you will need to change the interface to ``public``." msgstr "" #: ../../source/user/aio/quickstart.rst:389 msgid "" "If the AIO was deployed in a cloud VM, you may need to configure security " "groups or firewall rules to allow access to the various sevice ports. For " "example, if the AIO was deployed in an OpenStack VM, you can create and " "apply a suitable security group for interacting the core services like so:" msgstr "" #: ../../source/user/aio/quickstart.rst:410 msgid "" "If you have enabled SSL certificate configuration (default), all services " "will use self-signed certificates. While the host is configured to trust " "these certificates, this is not the case for other hosts. This will result " "in HTTPS errors when attempting to interact with the cloud. To resolve this " "issue, you will need to manually configure certificates on other hosts or " "ignore SSL issues. To use the self-signed certificate, first copy it to the " "other hosts. The name and location of the generated certificate are " "configured by the ``pki_authorities`` and ``pki_trust_store_location`` " "variables respectively, which are used by the ``pki`` role provided by " "`ansible-role-pki`__. On an Ubuntu 22.04 host, these will default to " "``ExampleCorpRoot`` and ``/usr/local/share/ca-certificates``, respectively. " "For example:" msgstr "" #: ../../source/user/aio/quickstart.rst:429 msgid "" "Once this is done, configure the ``cacert`` value in the the definition for " "your cloud in ``clouds.yaml``. For example:" msgstr "" #: ../../source/user/aio/quickstart.rst:439 msgid "" "Alternatively, you can simply ignore SSL issues by setting ``verify: false`` " "in the definition for your cloud in ``clouds.yaml``. This will disable SSL " "verification entirely for this cloud. For example:" msgstr "" #: ../../source/user/aio/quickstart.rst:450 msgid "" "Finally, you can also opt to disable SSL certificate configuration during " "initial deployment or opt to use an external certificate authority for " "signing, such as Lets Encrypt. Both topics are outside the scope of this " "document." msgstr "" #: ../../source/user/aio/quickstart.rst:455 msgid "" "More information about SSL certificate configuration can be found in the :" "doc:`security guide `." msgstr "" #: ../../source/user/aio/quickstart.rst:458 msgid "" "Once one of these files have been created, you can use it to interact with " "your deployment using most standard clients and libraries. For example, to " "list available projects using *openstackclient*:" msgstr "" #: ../../source/user/aio/quickstart.rst:470 msgid "Rebooting an AIO" msgstr "" #: ../../source/user/aio/quickstart.rst:472 msgid "" "As the AIO includes all three cluster members of MariaDB/Galera, the cluster " "has to be re-initialized after the host is rebooted." msgstr "" #: ../../source/user/aio/quickstart.rst:475 msgid "This is done by executing the following:" msgstr "" #: ../../source/user/aio/quickstart.rst:482 msgid "" "If this fails to get the database cluster back into a running state, then " "please make use of the `Galera Cluster Recovery `_ section in the operations guide." msgstr "" #: ../../source/user/aio/quickstart.rst:488 msgid "Rebuilding an AIO" msgstr "" #: ../../source/user/aio/quickstart.rst:490 msgid "" "Sometimes it may be useful to destroy all the containers and rebuild the AIO." " While it is preferred that the AIO is entirely destroyed and rebuilt, this " "isn't always practical. As such the following may be executed instead:" msgstr "" #: ../../source/user/aio/quickstart.rst:525 msgid "" "Should an existing AIO environment need to be reinstalled, the most " "efficient method is to destroy the host operating system and start over. For " "this reason, AIOs are best run inside of some form of virtual machine or " "cloud guest." msgstr "" #: ../../source/user/aio/quickstart.rst:530 msgid "Reference Diagram for an AIO Build" msgstr "" #: ../../source/user/aio/quickstart.rst:532 msgid "" "Here is a basic diagram that attempts to illustrate what the resulting AIO " "deployment looks like." msgstr "" #: ../../source/user/aio/quickstart.rst:535 msgid "" "This diagram is not to scale and is not even 100% accurate, this diagram was " "built for informational purposes only and should **ONLY** be used as such." msgstr "" #: ../../source/user/ceph/ceilometer.rst:3 msgid "Integrate radosgw into your Telemetry" msgstr "" #: ../../source/user/ceph/ceilometer.rst:5 msgid "" "The telemetry (and in consequence accounting) for radosgw as object-storage " "will not work out of the box. You need to change different parts of your " "OpenStack and Ceph setup to get it up and running." msgstr "" #: ../../source/user/ceph/ceilometer.rst:11 msgid "Ceilometer Changes" msgstr "" #: ../../source/user/ceph/ceilometer.rst:14 msgid "" "Ceilometer needs additional pip packages to talk to Ceph Rados Gateway. To " "install it, edit the default ceilometer_pip_packages in your user_variables." "yml file:" msgstr "" #: ../../source/user/ceph/ceilometer.rst:34 msgid "" "You also have to configure Ceilometer to actually query radosgw. When your " "ceilometer isn't configured to poll everything, add these pollsters to your " "polling.yml file:" msgstr "" #: ../../source/user/ceph/ceilometer.rst:51 msgid "Add them also to your pipeline:" msgstr "" #: ../../source/user/ceph/ceilometer.rst:67 msgid "" "Declare Ceph Rados Gateway as object-store in your ceilometer.conf file by " "adding this to your user_variables.yml file:" msgstr "" #: ../../source/user/ceph/ceilometer.rst:79 msgid "The required user and credentials is created by this command:" msgstr "" #: ../../source/user/ceph/ceilometer.rst:85 msgid "To get your credentials, execute:" msgstr "" #: ../../source/user/ceph/ceilometer.rst:92 msgid "Ceph Changes" msgstr "" #: ../../source/user/ceph/ceilometer.rst:94 msgid "" "The required changes are described in the documentation of Ceilometer. This " "is just a sum up. In your ceph.conf add:" msgstr "" #: ../../source/user/ceph/full-deploy.rst:5 msgid "Ceph production example" msgstr "" #: ../../source/user/ceph/full-deploy.rst:7 msgid "" "This section describes an example production environment for a working " "OpenStack-Ansible (OSA) deployment with high availability services and using " "the Ceph backend for images, volumes, and instances." msgstr "" #: ../../source/user/ceph/full-deploy.rst:11 #: ../../source/user/l3pods/example.rst:12 #: ../../source/user/prod/example.rst:10 #: ../../source/user/prod/provnet_groups.rst:22 #: ../../source/user/test/example.rst:8 msgid "This example environment has the following characteristics:" msgstr "" #: ../../source/user/ceph/full-deploy.rst:13 msgid "Three infrastructure (control plane) hosts with ceph-mon containers" msgstr "" #: ../../source/user/ceph/full-deploy.rst:14 #: ../../source/user/l3pods/example.rst:15 #: ../../source/user/prod/example.rst:13 msgid "Two compute hosts" msgstr "" #: ../../source/user/ceph/full-deploy.rst:15 msgid "Three Ceph OSD storage hosts" msgstr "" #: ../../source/user/ceph/full-deploy.rst:16 #: ../../source/user/l3pods/example.rst:17 #: ../../source/user/prod/example.rst:15 msgid "One log aggregation host" msgstr "" #: ../../source/user/ceph/full-deploy.rst:17 #: ../../source/user/l3pods/example.rst:18 #: ../../source/user/prod/example.rst:16 msgid "" "Multiple Network Interface Cards (NIC) configured as bonded pairs for each " "host" msgstr "" #: ../../source/user/ceph/full-deploy.rst:19 msgid "" "Full compute kit with the Telemetry service (ceilometer) included, with Ceph " "configured as a storage back end for the Image (glance), and Block Storage " "(cinder) services" msgstr "" #: ../../source/user/ceph/full-deploy.rst:22 #: ../../source/user/prod/example.rst:21 ../../source/user/test/example.rst:15 msgid "" "Internet access via the router address 172.29.236.1 on the Management " "Network" msgstr "" #: ../../source/user/ceph/full-deploy.rst:29 msgid "Integration with Ceph" msgstr "" #: ../../source/user/ceph/full-deploy.rst:31 msgid "" "OpenStack-Ansible allows `Ceph storage `_ cluster " "integration in three ways:" msgstr "" #: ../../source/user/ceph/full-deploy.rst:34 msgid "" "connecting to your own pre-deployed ceph cluster by pointing to its " "information in ``user_variables.yml`` and allowing openstack-ansible to ssh " "to the ceph monitors to retrieve the contents of ceph.conf and the keyrings." msgstr "" #: ../../source/user/ceph/full-deploy.rst:39 msgid "" "This method only requires a very small amount of configuration in " "``user_variables.yml`` to point to the external ceph cluster monitors. The " "whole configuration for ceph-ansible would live outside the openstack-" "ansible deployment and there is no duplication. The ``ceph_mons`` variable " "expects a list of IP addresses for the Ceph Monitor servers in the external " "ceph deployment:" msgstr "" #: ../../source/user/ceph/full-deploy.rst:48 msgid "" "Overriding ceph_mons is required only when you are using external cluster " "which does not present in the OpenStack-Ansible's inventory (ie group " "``mon_group_name`` is not defined)." msgstr "" #: ../../source/user/ceph/full-deploy.rst:59 msgid "" "connecting to your own pre-deployed ceph cluster by pointing to its monitors " "in ``user_variables.yml`` as above and providing data to populate ceph.conf " "and ceph keyring files on the deploy host. This is described `here `_. No ssh access by openstack-ansible is required to the ceph cluster." msgstr "" #: ../../source/user/ceph/full-deploy.rst:64 msgid "" "deploying a ceph cluster as part of the openstack-ansible deployment by " "using the roles maintained by the `Ceph-Ansible`_ project. Deployers can " "enable the ``ceph-install.yml`` playbook by adding hosts to the ``ceph-" "mon_hosts`` and ``ceph-osd_hosts`` groups in ``openstack_user_config.yml``. " "In order to enable ``ceph-rgw-install.yml`` playbook you need to add ``ceph-" "rgw_hosts`` in ``openstack_user_config.yml``." msgstr "" #: ../../source/user/ceph/full-deploy.rst:73 msgid "" "Please mention, that RGW installation should be performed after deployment " "of Keystone service." msgstr "" #: ../../source/user/ceph/full-deploy.rst:76 msgid "" "Once groups are defined, you can proceed with configuring `Ceph-Ansible " "specific vars `_ in the OpenStack-Ansible ``user_variables.yml`` file." msgstr "" #: ../../source/user/ceph/full-deploy.rst:82 msgid "" "Deploying ceph cluster as part of openstack-ansible is not recommended since " "ceph-ansible upgrade path is not tested or supported. This option is mainly " "used for CI and AIO deployments to test and demonstrate a sample integration " "of the software stack." msgstr "" #: ../../source/user/ceph/full-deploy.rst:89 msgid "" "This example will focus on the deployment of both OpenStack-Ansible and its " "Ceph cluster." msgstr "" #: ../../source/user/ceph/full-deploy.rst:93 #: ../../source/user/l3pods/example.rst:31 #: ../../source/user/prod/example.rst:29 ../../source/user/test/example.rst:23 msgid "Network configuration" msgstr "" #: ../../source/user/ceph/full-deploy.rst:96 #: ../../source/user/l3pods/example.rst:34 #: ../../source/user/prod/example.rst:32 ../../source/user/test/example.rst:39 msgid "Network CIDR/VLAN assignments" msgstr "" #: ../../source/user/ceph/full-deploy.rst:98 #: ../../source/user/prod/example.rst:34 ../../source/user/test/example.rst:41 msgid "The following CIDR and VLAN assignments are used for this environment." msgstr "" #: ../../source/user/ceph/full-deploy.rst:101 #: ../../source/user/l3pods/example.rst:39 #: ../../source/user/network-arch/example.rst:17 #: ../../source/user/prod/example.rst:37 ../../source/user/test/example.rst:44 msgid "CIDR" msgstr "" #: ../../source/user/ceph/full-deploy.rst:101 #: ../../source/user/l3pods/example.rst:39 #: ../../source/user/network-arch/example.rst:17 #: ../../source/user/prod/example.rst:37 ../../source/user/test/example.rst:44 msgid "Network" msgstr "" #: ../../source/user/ceph/full-deploy.rst:101 #: ../../source/user/l3pods/example.rst:39 #: ../../source/user/network-arch/example.rst:17 #: ../../source/user/prod/example.rst:37 ../../source/user/test/example.rst:44 msgid "VLAN" msgstr "" #: ../../source/user/ceph/full-deploy.rst:103 #: ../../source/user/l3pods/example.rst:41 #: ../../source/user/l3pods/example.rst:47 #: ../../source/user/l3pods/example.rst:53 #: ../../source/user/l3pods/example.rst:59 #: ../../source/user/network-arch/example.rst:19 #: ../../source/user/prod/example.rst:39 ../../source/user/test/example.rst:46 msgid "10" msgstr "" #: ../../source/user/ceph/full-deploy.rst:103 #: ../../source/user/network-arch/example.rst:19 #: ../../source/user/prod/example.rst:39 ../../source/user/test/example.rst:46 msgid "172.29.236.0/22" msgstr "" #: ../../source/user/ceph/full-deploy.rst:103 #: ../../source/user/network-arch/example.rst:19 #: ../../source/user/prod/example.rst:39 ../../source/user/test/example.rst:46 msgid "Management Network" msgstr "" #: ../../source/user/ceph/full-deploy.rst:105 #: ../../source/user/network-arch/example.rst:21 #: ../../source/user/prod/example.rst:41 ../../source/user/test/example.rst:48 msgid "172.29.240.0/22" msgstr "" #: ../../source/user/ceph/full-deploy.rst:105 #: ../../source/user/l3pods/example.rst:43 #: ../../source/user/l3pods/example.rst:49 #: ../../source/user/l3pods/example.rst:55 #: ../../source/user/l3pods/example.rst:61 #: ../../source/user/network-arch/example.rst:21 #: ../../source/user/prod/example.rst:41 ../../source/user/test/example.rst:48 msgid "30" msgstr "" #: ../../source/user/ceph/full-deploy.rst:105 #: ../../source/user/prod/example.rst:41 ../../source/user/test/example.rst:48 msgid "Tunnel (VXLAN) Network" msgstr "" #: ../../source/user/ceph/full-deploy.rst:107 #: ../../source/user/network-arch/example.rst:23 #: ../../source/user/prod/example.rst:43 ../../source/user/test/example.rst:50 msgid "172.29.244.0/22" msgstr "" #: ../../source/user/ceph/full-deploy.rst:107 #: ../../source/user/l3pods/example.rst:45 #: ../../source/user/l3pods/example.rst:51 #: ../../source/user/l3pods/example.rst:57 #: ../../source/user/l3pods/example.rst:63 #: ../../source/user/network-arch/example.rst:23 #: ../../source/user/prod/example.rst:43 ../../source/user/test/example.rst:50 msgid "20" msgstr "" #: ../../source/user/ceph/full-deploy.rst:107 #: ../../source/user/network-arch/example.rst:23 #: ../../source/user/prod/example.rst:43 ../../source/user/test/example.rst:50 msgid "Storage Network" msgstr "" #: ../../source/user/ceph/full-deploy.rst:111 #: ../../source/user/l3pods/example.rst:67 #: ../../source/user/prod/example.rst:47 ../../source/user/test/example.rst:54 msgid "IP assignments" msgstr "" #: ../../source/user/ceph/full-deploy.rst:113 #: ../../source/user/l3pods/example.rst:69 #: ../../source/user/prod/example.rst:49 ../../source/user/test/example.rst:56 msgid "" "The following host name and IP address assignments are used for this " "environment." msgstr "" #: ../../source/user/ceph/full-deploy.rst:117 #: ../../source/user/l3pods/example.rst:73 #: ../../source/user/prod/example.rst:53 ../../source/user/test/example.rst:60 msgid "Host name" msgstr "" #: ../../source/user/ceph/full-deploy.rst:117 #: ../../source/user/l3pods/example.rst:73 #: ../../source/user/prod/example.rst:53 ../../source/user/test/example.rst:60 msgid "Management IP" msgstr "" #: ../../source/user/ceph/full-deploy.rst:117 #: ../../source/user/l3pods/example.rst:73 #: ../../source/user/prod/example.rst:53 ../../source/user/test/example.rst:60 msgid "Storage IP" msgstr "" #: ../../source/user/ceph/full-deploy.rst:117 #: ../../source/user/l3pods/example.rst:73 #: ../../source/user/prod/example.rst:53 ../../source/user/test/example.rst:60 msgid "Tunnel (VxLAN) IP" msgstr "" #: ../../source/user/ceph/full-deploy.rst:119 #: ../../source/user/l3pods/example.rst:75 #: ../../source/user/prod/example.rst:55 msgid "172.29.236.9" msgstr "" #: ../../source/user/ceph/full-deploy.rst:119 #: ../../source/user/l3pods/example.rst:75 #: ../../source/user/prod/example.rst:55 msgid "lb_vip_address" msgstr "" #: ../../source/user/ceph/full-deploy.rst:121 #: ../../source/user/l3pods/example.rst:83 #: ../../source/user/prod/example.rst:57 ../../source/user/test/example.rst:62 msgid "172.29.236.11" msgstr "" #: ../../source/user/ceph/full-deploy.rst:121 #: ../../source/user/prod/example.rst:57 ../../source/user/test/example.rst:62 msgid "172.29.240.11" msgstr "" #: ../../source/user/ceph/full-deploy.rst:121 #: ../../source/user/l3pods/example.rst:77 #: ../../source/user/prod/example.rst:57 ../../source/user/test/example.rst:62 msgid "infra1" msgstr "" #: ../../source/user/ceph/full-deploy.rst:123 #: ../../source/user/prod/example.rst:59 ../../source/user/test/example.rst:64 msgid "172.29.236.12" msgstr "" #: ../../source/user/ceph/full-deploy.rst:123 #: ../../source/user/prod/example.rst:59 ../../source/user/test/example.rst:64 msgid "172.29.240.12" msgstr "" #: ../../source/user/ceph/full-deploy.rst:123 #: ../../source/user/l3pods/example.rst:79 #: ../../source/user/prod/example.rst:59 msgid "infra2" msgstr "" #: ../../source/user/ceph/full-deploy.rst:125 #: ../../source/user/prod/example.rst:61 ../../source/user/test/example.rst:66 msgid "172.29.236.13" msgstr "" #: ../../source/user/ceph/full-deploy.rst:125 #: ../../source/user/prod/example.rst:61 msgid "172.29.240.13" msgstr "" #: ../../source/user/ceph/full-deploy.rst:125 #: ../../source/user/l3pods/example.rst:81 #: ../../source/user/prod/example.rst:61 msgid "infra3" msgstr "" #: ../../source/user/ceph/full-deploy.rst:127 #: ../../source/user/prod/example.rst:63 msgid "172.29.236.14" msgstr "" #: ../../source/user/ceph/full-deploy.rst:127 #: ../../source/user/l3pods/example.rst:83 #: ../../source/user/prod/example.rst:63 msgid "log1" msgstr "" #: ../../source/user/ceph/full-deploy.rst:129 #: ../../source/user/prod/example.rst:67 msgid "172.29.236.16" msgstr "" #: ../../source/user/ceph/full-deploy.rst:129 #: ../../source/user/prod/example.rst:67 msgid "172.29.240.16" msgstr "" #: ../../source/user/ceph/full-deploy.rst:129 #: ../../source/user/prod/example.rst:67 msgid "172.29.244.16" msgstr "" #: ../../source/user/ceph/full-deploy.rst:129 #: ../../source/user/l3pods/example.rst:87 #: ../../source/user/prod/example.rst:67 ../../source/user/test/example.rst:64 msgid "compute1" msgstr "" #: ../../source/user/ceph/full-deploy.rst:131 #: ../../source/user/prod/example.rst:69 msgid "172.29.236.17" msgstr "" #: ../../source/user/ceph/full-deploy.rst:131 #: ../../source/user/prod/example.rst:69 msgid "172.29.240.17" msgstr "" #: ../../source/user/ceph/full-deploy.rst:131 #: ../../source/user/prod/example.rst:69 msgid "172.29.244.17" msgstr "" #: ../../source/user/ceph/full-deploy.rst:131 #: ../../source/user/l3pods/example.rst:89 #: ../../source/user/prod/example.rst:69 msgid "compute2" msgstr "" #: ../../source/user/ceph/full-deploy.rst:133 msgid "172.29.236.18" msgstr "" #: ../../source/user/ceph/full-deploy.rst:133 msgid "172.29.244.18" msgstr "" #: ../../source/user/ceph/full-deploy.rst:133 msgid "osd1" msgstr "" #: ../../source/user/ceph/full-deploy.rst:135 msgid "172.29.236.19" msgstr "" #: ../../source/user/ceph/full-deploy.rst:135 msgid "172.29.244.19" msgstr "" #: ../../source/user/ceph/full-deploy.rst:135 msgid "osd2" msgstr "" #: ../../source/user/ceph/full-deploy.rst:137 msgid "172.29.236.20" msgstr "" #: ../../source/user/ceph/full-deploy.rst:137 msgid "172.29.244.20" msgstr "" #: ../../source/user/ceph/full-deploy.rst:137 msgid "osd3" msgstr "" #: ../../source/user/ceph/full-deploy.rst:141 #: ../../source/user/l3pods/example.rst:93 #: ../../source/user/prod/example.rst:73 ../../source/user/test/example.rst:70 msgid "Host network configuration" msgstr "" #: ../../source/user/ceph/full-deploy.rst:143 #: ../../source/user/l3pods/example.rst:95 #: ../../source/user/prod/example.rst:75 ../../source/user/test/example.rst:72 msgid "" "Each host will require the correct network bridges to be implemented. The " "following is the ``/etc/network/interfaces`` file for ``infra1``." msgstr "" #: ../../source/user/ceph/full-deploy.rst:148 #: ../../source/user/l3pods/example.rst:100 #: ../../source/user/network-arch/example.rst:183 #: ../../source/user/network-arch/example.rst:241 #: ../../source/user/prod/example.rst:80 ../../source/user/test/example.rst:77 msgid "" "If your environment does not have ``eth0``, but instead has ``p1p1`` or some " "other interface name, ensure that all references to ``eth0`` in all " "configuration files are replaced with the appropriate name. The same applies " "to additional network interfaces." msgstr "" #: ../../source/user/ceph/full-deploy.rst:156 #: ../../source/user/l3pods/example.rst:108 #: ../../source/user/prod/example.rst:88 #: ../../source/user/prod/provnet_groups.rst:53 #: ../../source/user/test/example.rst:85 msgid "Deployment configuration" msgstr "" #: ../../source/user/ceph/full-deploy.rst:159 #: ../../source/user/l3pods/example.rst:111 #: ../../source/user/prod/example.rst:91 #: ../../source/user/prod/provnet_groups.rst:56 #: ../../source/user/test/example.rst:88 msgid "Environment layout" msgstr "" #: ../../source/user/ceph/full-deploy.rst:161 #: ../../source/user/l3pods/example.rst:113 #: ../../source/user/prod/example.rst:93 #: ../../source/user/prod/provnet_groups.rst:58 #: ../../source/user/test/example.rst:90 msgid "" "The ``/etc/openstack_deploy/openstack_user_config.yml`` file defines the " "environment layout." msgstr "" #: ../../source/user/ceph/full-deploy.rst:164 #: ../../source/user/l3pods/example.rst:128 #: ../../source/user/prod/example.rst:96 #: ../../source/user/prod/provnet_groups.rst:61 #: ../../source/user/test/example.rst:93 msgid "The following configuration describes the layout for this environment." msgstr "" #: ../../source/user/ceph/full-deploy.rst:169 #: ../../source/user/l3pods/example.rst:133 #: ../../source/user/prod/example.rst:101 ../../source/user/test/example.rst:98 msgid "Environment customizations" msgstr "" #: ../../source/user/ceph/full-deploy.rst:171 #: ../../source/user/l3pods/example.rst:135 #: ../../source/user/prod/example.rst:103 #: ../../source/user/test/example.rst:100 msgid "" "The optionally deployed files in ``/etc/openstack_deploy/env.d`` allow the " "customization of Ansible groups. This allows the deployer to set whether the " "services will run in a container (the default), or on the host (on metal)." msgstr "" #: ../../source/user/ceph/full-deploy.rst:176 msgid "" "For a ceph environment, you can run the ``cinder-volume`` in a container. To " "do this you will need to create a ``/etc/openstack_deploy/env.d/cinder.yml`` " "file with the following content:" msgstr "" #: ../../source/user/ceph/full-deploy.rst:184 #: ../../source/user/l3pods/example.rst:163 #: ../../source/user/prod/example.rst:115 #: ../../source/user/test/example.rst:109 msgid "User variables" msgstr "" #: ../../source/user/ceph/full-deploy.rst:186 #: ../../source/user/l3pods/example.rst:165 #: ../../source/user/prod/example.rst:117 #: ../../source/user/test/example.rst:111 msgid "" "The ``/etc/openstack_deploy/user_variables.yml`` file defines the global " "overrides for the default variables." msgstr "" #: ../../source/user/ceph/full-deploy.rst:189 msgid "" "For this example environment, we configure a HA load balancer. We implement " "the load balancer (HAProxy) with an HA layer (keepalived) on the " "infrastructure hosts. Your ``/etc/openstack_deploy/user_variables.yml`` must " "have the following content to configure haproxy, keepalived and ceph:" msgstr "" #: ../../source/user/ceph/swift.rst:3 msgid "Using radosgw as a drop-in replacement for Swift" msgstr "" #: ../../source/user/ceph/swift.rst:5 msgid "" "OpenStack-Ansible gives you the option of deploying radosgw as a drop-in " "replacement for native OpenStack Swift." msgstr "" #: ../../source/user/ceph/swift.rst:8 msgid "" "In particular, the ``ceph-rgw-install.yml`` playbook (which includes ``ceph-" "rgw-keystone-setup.yml``) will deploy radosgw to any ``ceph-rgw`` hosts, and " "create a corresponding Keystone ``object-store`` service catalog entry. The " "service endpoints do contain the ``AUTH_%(tenant_id)s`` prefix just like in " "native Swift, so public read ACLs and temp URLs will work just like they do " "in Swift." msgstr "" #: ../../source/user/ceph/swift.rst:16 msgid "By default, OSA enables *only* the Swift API in radosgw." msgstr "" #: ../../source/user/ceph/swift.rst:20 msgid "Adding S3 API support" msgstr "" #: ../../source/user/ceph/swift.rst:22 msgid "" "You may want to enable the default radosgw S3 API, in addition to the Swift " "API. In order to do so, you need to override the ``ceph_conf_overrides_rgw`` " "variable in ``user_variables.yml``. Below is an example configuration " "snippet:" msgstr "" #: ../../source/user/ceph/swift.rst:29 msgid "" "Mentioned below overrides are default ones and will be applied to `ceph-rgw` " "group" msgstr "" #: ../../source/user/ceph/swift.rst:33 msgid "" "You may also want to add the ``rgw_dns_name`` option if you want to enable " "bucket hostnames with the S3 API." msgstr "" #: ../../source/user/index.rst:3 msgid "User Guide" msgstr "" #: ../../source/user/index.rst:5 msgid "" "In this section, you will find user stories and examples relevant to " "deploying OpenStack-Ansible." msgstr "" #: ../../source/user/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/user/index.rst:13 msgid "" "For information on how to manage and operate OpenStack-Ansible, see the see " "the :dev_docs:`Operations Guide `." msgstr "" #: ../../source/user/index.rst:16 msgid "" "For information on how to contribute, extend or develop OpenStack-Ansible, " "see the :dev_docs:`Contributors Guide `." msgstr "" #: ../../source/user/index.rst:19 msgid "" "For in-depth technical information, see the :dev_docs:`OpenStack-Ansible " "Reference `." msgstr "" #: ../../source/user/l3pods/example.rst:5 msgid "Routed environment example" msgstr "" #: ../../source/user/l3pods/example.rst:7 msgid "" "This section describes an example production environment for a working " "OpenStack-Ansible (OSA) deployment with high availability services where " "provider networks and connectivity between physical machines are routed " "(layer 3)." msgstr "" #: ../../source/user/l3pods/example.rst:14 #: ../../source/user/prod/example.rst:12 msgid "Three infrastructure (control plane) hosts" msgstr "" #: ../../source/user/l3pods/example.rst:16 #: ../../source/user/prod/example.rst:14 msgid "One NFS storage device" msgstr "" #: ../../source/user/l3pods/example.rst:20 msgid "" "Full compute kit with the Telemetry service (ceilometer) included, with NFS " "configured as a storage backend for the Image (glance), and Block Storage " "(cinder) services" msgstr "" #: ../../source/user/l3pods/example.rst:23 msgid "" "Static routes are added to allow communication between the Management, " "Tunnel, and Storage Networks of each pod. The gateway address is the first " "usable address within each network's subnet." msgstr "" #: ../../source/user/l3pods/example.rst:36 msgid "The following CIDR assignments are used for this environment." msgstr "" #: ../../source/user/l3pods/example.rst:41 msgid "172.29.236.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:41 msgid "POD 1 Management Network" msgstr "" #: ../../source/user/l3pods/example.rst:43 msgid "172.29.237.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:43 msgid "POD 1 Tunnel (VXLAN) Network" msgstr "" #: ../../source/user/l3pods/example.rst:45 msgid "172.29.238.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:45 msgid "POD 1 Storage Network" msgstr "" #: ../../source/user/l3pods/example.rst:47 msgid "172.29.239.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:47 msgid "POD 2 Management Network" msgstr "" #: ../../source/user/l3pods/example.rst:49 msgid "172.29.240.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:49 msgid "POD 2 Tunnel (VXLAN) Network" msgstr "" #: ../../source/user/l3pods/example.rst:51 msgid "172.29.241.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:51 msgid "POD 2 Storage Network" msgstr "" #: ../../source/user/l3pods/example.rst:53 msgid "172.29.242.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:53 msgid "POD 3 Management Network" msgstr "" #: ../../source/user/l3pods/example.rst:55 msgid "172.29.243.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:55 msgid "POD 3 Tunnel (VXLAN) Network" msgstr "" #: ../../source/user/l3pods/example.rst:57 msgid "172.29.244.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:57 msgid "POD 3 Storage Network" msgstr "" #: ../../source/user/l3pods/example.rst:59 msgid "172.29.245.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:59 msgid "POD 4 Management Network" msgstr "" #: ../../source/user/l3pods/example.rst:61 msgid "172.29.246.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:61 msgid "POD 4 Tunnel (VXLAN) Network" msgstr "" #: ../../source/user/l3pods/example.rst:63 msgid "172.29.247.0/24" msgstr "" #: ../../source/user/l3pods/example.rst:63 msgid "POD 4 Storage Network" msgstr "" #: ../../source/user/l3pods/example.rst:77 msgid "172.29.236.10" msgstr "" #: ../../source/user/l3pods/example.rst:77 msgid "172.29.237.10" msgstr "" #: ../../source/user/l3pods/example.rst:79 msgid "172.29.239.10" msgstr "" #: ../../source/user/l3pods/example.rst:79 msgid "172.29.240.10" msgstr "" #: ../../source/user/l3pods/example.rst:81 msgid "172.29.242.10" msgstr "" #: ../../source/user/l3pods/example.rst:81 msgid "172.29.243.10" msgstr "" #: ../../source/user/l3pods/example.rst:85 #: ../../source/user/prod/example.rst:65 msgid "172.29.244.15" msgstr "" #: ../../source/user/l3pods/example.rst:85 #: ../../source/user/prod/example.rst:65 msgid "NFS Storage" msgstr "" #: ../../source/user/l3pods/example.rst:87 msgid "172.29.245.10" msgstr "" #: ../../source/user/l3pods/example.rst:87 msgid "172.29.246.10" msgstr "" #: ../../source/user/l3pods/example.rst:87 msgid "172.29.247.10" msgstr "" #: ../../source/user/l3pods/example.rst:89 msgid "172.29.245.11" msgstr "" #: ../../source/user/l3pods/example.rst:89 msgid "172.29.246.11" msgstr "" #: ../../source/user/l3pods/example.rst:89 msgid "172.29.247.11" msgstr "" #: ../../source/user/l3pods/example.rst:116 msgid "" "For each pod, a group will need to be defined containing all hosts within " "that pod." msgstr "" #: ../../source/user/l3pods/example.rst:119 msgid "" "Within defined provider networks, ``address_prefix`` is used to override the " "prefix of the key added to each host that contains IP address information. " "This should usually be one of either ``container``, ``tunnel``, or " "``storage``. ``reference_group`` contains the name of a defined pod group " "and is used to limit the scope of each provider network to that group." msgstr "" #: ../../source/user/l3pods/example.rst:125 msgid "" "Static routes are added to allow communication of provider networks between " "pods." msgstr "" #: ../../source/user/l3pods/example.rst:140 #: ../../source/user/prod/example.rst:108 msgid "" "For this environment, the ``cinder-volume`` runs in a container on the " "infrastructure hosts. To achieve this, implement ``/etc/openstack_deploy/env." "d/cinder.yml`` with the following content:" msgstr "" #: ../../source/user/l3pods/example.rst:146 msgid "" "You can also declare a custom group for each pod that will also include all " "containers from hosts that belong to this pod. This might be handy if you " "want to define some variable for all hosts in the pod using group_variables." msgstr "" #: ../../source/user/l3pods/example.rst:150 msgid "" "For that create ``/etc/openstack_deploy/env.d/pod.yml`` with the following " "content:" msgstr "" #: ../../source/user/l3pods/example.rst:154 msgid "Above example will create following groups:" msgstr "" #: ../../source/user/l3pods/example.rst:156 msgid "``podN_hosts`` which will contain only bare metal nodes" msgstr "" #: ../../source/user/l3pods/example.rst:157 msgid "" "``podN_containers`` that will contain all containers that are spawned on" msgstr "" #: ../../source/user/l3pods/example.rst:158 msgid "bare metal nodes, that are part of the pod." msgstr "" #: ../../source/user/l3pods/example.rst:159 msgid "" "``podN_all`` that will contain `podN_hosts` and `podN_containers` members" msgstr "" #: ../../source/user/l3pods/example.rst:168 #: ../../source/user/prod/example.rst:120 msgid "" "For this environment, implement the load balancer on the infrastructure " "hosts. Ensure that keepalived is also configured with HAProxy in ``/etc/" "openstack_deploy/user_variables.yml`` with the following content." msgstr "" #: ../../source/user/limited-connectivity/index.rst:5 msgid "Installing with limited connectivity" msgstr "" #: ../../source/user/limited-connectivity/index.rst:7 msgid "" "Many playbooks and roles in OpenStack-Ansible retrieve dependencies from the " "public Internet by default. The example configurations assume that the " "deployer provides a good quality Internet connection via a router on the " "OpenStack management network." msgstr "" #: ../../source/user/limited-connectivity/index.rst:12 msgid "" "Deployments may encounter limited external connectivity for a number of " "reasons:" msgstr "" #: ../../source/user/limited-connectivity/index.rst:15 msgid "Unreliable or low bandwidth external connectivity" msgstr "" #: ../../source/user/limited-connectivity/index.rst:16 msgid "Firewall rules which block external connectivity" msgstr "" #: ../../source/user/limited-connectivity/index.rst:17 msgid "External connectivity required to be via HTTP or SOCKS proxies" msgstr "" #: ../../source/user/limited-connectivity/index.rst:18 msgid "" "Architectural decisions by the deployer to isolate the OpenStack networks" msgstr "" #: ../../source/user/limited-connectivity/index.rst:19 msgid "High security environments where no external connectivity is permitted" msgstr "" #: ../../source/user/limited-connectivity/index.rst:21 msgid "" "When running OpenStack-Ansible in network environments that block internet " "connectivity, we recommend the following set of practices and configuration " "overrides for deployers to use." msgstr "" #: ../../source/user/limited-connectivity/index.rst:25 msgid "" "The options below are not mutually exclusive and may be combined if desired." msgstr "" #: ../../source/user/limited-connectivity/index.rst:28 msgid "Example internet dependencies" msgstr "" #: ../../source/user/limited-connectivity/index.rst:30 msgid "Python packages" msgstr "" #: ../../source/user/limited-connectivity/index.rst:31 #: ../../source/user/limited-connectivity/index.rst:85 msgid "Distribution specific packages" msgstr "" #: ../../source/user/limited-connectivity/index.rst:32 #: ../../source/user/limited-connectivity/index.rst:113 msgid "LXC container images" msgstr "" #: ../../source/user/limited-connectivity/index.rst:33 #: ../../source/user/limited-connectivity/index.rst:123 msgid "Source code repositories" msgstr "" #: ../../source/user/limited-connectivity/index.rst:34 msgid "GPG keys for package validation" msgstr "" #: ../../source/user/limited-connectivity/index.rst:37 msgid "Practice A: Mirror internet resources locally" msgstr "" #: ../../source/user/limited-connectivity/index.rst:39 msgid "" "You may choose to operate and maintain mirrors of OpenStack-Ansible and " "OpenStack dependencies. Mirrors often provide a great deal of risk " "mitigation by reducing dependencies on resources and systems outside of your " "direct control. Mirrors can also provide greater stability, performance and " "security." msgstr "" #: ../../source/user/limited-connectivity/index.rst:45 msgid "Python package repositories" msgstr "" #: ../../source/user/limited-connectivity/index.rst:47 msgid "" "Many packages used to run OpenStack are installed using `pip`. We advise " "mirroring the PyPi package index used by `pip`. A deployer can choose to " "actively mirror the entire upstream PyPi repository, but this may require a " "significant amount of storage. Alternatively, a caching pip proxy can be " "used to retain local copies of only those packages which are required." msgstr "" #: ../../source/user/limited-connectivity/index.rst:53 msgid "" "In order to configure the deployment to use an alternative index, create the " "file `/etc/pip.conf` with the following content and ensure that it resides " "on all hosts in the environment." msgstr "" #: ../../source/user/limited-connectivity/index.rst:62 msgid "" "In addition, it is necessary to configure easy_install to use an alternative " "index. easy_install is used instead of pip to install anything listed under " "setup_requires in setup.py during wheel builds. See https://pip.pypa.io/en/" "latest/reference/pip_install/#controlling-setup-requires" msgstr "" #: ../../source/user/limited-connectivity/index.rst:66 msgid "" "To configure easy_install to use an alternative index, create the file `/" "root/.pydistutils.cfg` with the following content." msgstr "" #: ../../source/user/limited-connectivity/index.rst:74 msgid "" "Then, in `/etc/openstack_deploy/user_variables.yml`, configure the " "deployment to copy these files from the host into the container cache image." msgstr "" #: ../../source/user/limited-connectivity/index.rst:87 msgid "" "Many software packages are installed on Ubuntu hosts using `.deb` packages. " "Similar packaging mechanisms exist for other Linux distributions. We advise " "mirroring the repositories that host these packages." msgstr "" #: ../../source/user/limited-connectivity/index.rst:91 msgid "Upstream Ubuntu repositories to mirror for Ubuntu 22.04 LTS:" msgstr "" #: ../../source/user/limited-connectivity/index.rst:93 msgid "jammy" msgstr "" #: ../../source/user/limited-connectivity/index.rst:94 msgid "jammy-updates" msgstr "" #: ../../source/user/limited-connectivity/index.rst:96 msgid "" "OpenStack-Ansible requires several other repositories to install specific " "components such as Galera and Ceph." msgstr "" #: ../../source/user/limited-connectivity/index.rst:99 msgid "Example repositories to mirror (Ubuntu target hosts):" msgstr "" #: ../../source/user/limited-connectivity/index.rst:101 msgid "https://download.ceph.com/" msgstr "" #: ../../source/user/limited-connectivity/index.rst:102 msgid "http://ubuntu-cloud.archive.canonical.com/ubuntu" msgstr "" #: ../../source/user/limited-connectivity/index.rst:103 msgid "https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang" msgstr "" #: ../../source/user/limited-connectivity/index.rst:104 msgid "https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server" msgstr "" #: ../../source/user/limited-connectivity/index.rst:105 msgid "http://downloads.mariadb.com/MariaDB" msgstr "" #: ../../source/user/limited-connectivity/index.rst:107 msgid "" "These lists are intentionally not exhaustive and equivalents will be " "required for other Linux distributions. Consult the OpenStack-Ansible " "playbooks and role documentation for further repositories and the variables " "that may be used to override the repository location." msgstr "" #: ../../source/user/limited-connectivity/index.rst:115 msgid "" "OpenStack-Ansible builds LXC images using debootstrap or dnf depending on " "the distribution. In order to override the package repository you might " "need to adjust some variables, like ``lxc_apt_mirror`` or completely " "override build command with ``lxc_hosts_container_build_command`` Consult " "the ``openstack-ansible-lxc_hosts`` role for details on configuration " "overrides for this scenario." msgstr "" #: ../../source/user/limited-connectivity/index.rst:125 msgid "" "OpenStack-Ansible relies upon Ansible Galaxy to download Ansible roles when " "bootstrapping a deployment host. Deployers may wish to mirror the " "dependencies that are downloaded by the ``bootstrap-ansible.sh`` script." msgstr "" #: ../../source/user/limited-connectivity/index.rst:129 msgid "" "Deployers can configure the script to source Ansible from an alternate Git " "repository by setting the environment variable ``ANSIBLE_GIT_REPO``. Also, " "during initial bootstrap you might need to define a custom URL for upper-" "constraints file that is part of `openstack/requirements` repository, using " "the TOX_CONSTRAINTS_FILE environment variable." msgstr "" #: ../../source/user/limited-connectivity/index.rst:135 msgid "" "Deployers can configure the script to source Ansible role dependencies from " "alternate locations by providing a custom role requirements file and " "specifying the path to that file using the environment variable " "``ANSIBLE_ROLE_FILE``." msgstr "" #: ../../source/user/limited-connectivity/index.rst:140 msgid "Practice B: Proxy access to internet resources" msgstr "" #: ../../source/user/limited-connectivity/index.rst:142 msgid "" "Some networks have no routed access to the Internet, or require certain " "traffic to use application specific gateways such as HTTP or SOCKS proxy " "servers." msgstr "" #: ../../source/user/limited-connectivity/index.rst:146 msgid "" "Target and deployment hosts can be configured to reach public internet " "resources via HTTP or SOCKS proxy server(s). OpenStack-Ansible may be used " "to configure target hosts to use the proxy server(s). OpenStack-Ansible does " "not provide automation for creating the proxy server(s)." msgstr "" #: ../../source/user/limited-connectivity/index.rst:151 msgid "" "Initial host deployment is outside the scope of OpenStack-Ansible and the " "deployer must ensure a minimum set of proxy configuration is in place, in " "particular for the system package manager." msgstr "" #: ../../source/user/limited-connectivity/index.rst:156 msgid "``apt-get`` proxy configuration" msgstr "" #: ../../source/user/limited-connectivity/index.rst:158 msgid "" "See `Setting up apt-get to use a http-proxy `_" msgstr "" #: ../../source/user/limited-connectivity/index.rst:161 msgid "Other proxy configuration" msgstr "" #: ../../source/user/limited-connectivity/index.rst:163 msgid "" "In addition to this basic configuration, there are other network clients on " "the target hosts which may be configured to connect via a proxy. For example:" "" msgstr "" #: ../../source/user/limited-connectivity/index.rst:166 msgid "Most Python network modules" msgstr "" #: ../../source/user/limited-connectivity/index.rst:167 msgid "`curl`" msgstr "" #: ../../source/user/limited-connectivity/index.rst:168 msgid "`wget`" msgstr "" #: ../../source/user/limited-connectivity/index.rst:169 msgid "`openstack`" msgstr "" #: ../../source/user/limited-connectivity/index.rst:171 msgid "" "These tools and their underlying libraries are used by Ansible itself and " "the OpenStack-Ansible playbooks, so there must be a proxy configuration in " "place for the playbooks to successfully access external resources." msgstr "" #: ../../source/user/limited-connectivity/index.rst:175 msgid "" "Typically these tools read environment variables containing proxy server " "settings. These environment variables can be configured in ``/etc/" "environment`` if required." msgstr "" #: ../../source/user/limited-connectivity/index.rst:179 msgid "" "It is important to note that the proxy server should only be used to access " "external resources, and communication between the internal components of the " "OpenStack deployment should be direct and not through the proxy. The " "``no_proxy`` environment variable is used to specify hosts that should be " "reached directly without going through the proxy. These often are the hosts " "in the management network." msgstr "" #: ../../source/user/limited-connectivity/index.rst:186 msgid "" "OpenStack-Ansible provides two distinct mechanisms for configuring proxy " "server settings:" msgstr "" #: ../../source/user/limited-connectivity/index.rst:189 msgid "" "1. The default configuration file suggests setting a persistent proxy " "configuration on all target hosts and defines a persistent ``no_proxy`` " "environment variable which lists all hosts/containers' management addresses " "as well as the load balancer internal/external addresses." msgstr "" #: ../../source/user/limited-connectivity/index.rst:194 msgid "" "2. An alternative method applies proxy configuration in a transient manner " "during the execution of Ansible playbooks and defines a minimum set of " "management network IP addresses for ``no_proxy`` that are required for the " "playbooks to succeed. These proxy settings do not persist after an Ansible " "playbook run and the completed deployment does not require them in order to " "be functional." msgstr "" #: ../../source/user/limited-connectivity/index.rst:201 msgid "" "The deployer must decide which of these approaches is more suitable for the " "target hosts, taking into account the following guidance:" msgstr "" #: ../../source/user/limited-connectivity/index.rst:204 msgid "" "1. Persistent proxy configuration is a standard practice and network clients " "on the target hosts will be able to access external resources after " "deployment." msgstr "" #: ../../source/user/limited-connectivity/index.rst:207 msgid "" "2. The deployer must ensure that a persistent proxy configuration has " "complete coverage of all OpenStack management network host/containers' IP " "addresses in the ``no_proxy`` environment variable. It is necessary to use a " "list of IP addresses, CIDR notation is not valid for ``no_proxy``." msgstr "" #: ../../source/user/limited-connectivity/index.rst:212 msgid "" "3. Transient proxy configuration guarantees that proxy environment variables " "will not persist, ensuring direct communication between services on the " "OpenStack management network after deployment. Target host network clients " "such as ``wget`` will not be able to access external resources after " "deployment." msgstr "" #: ../../source/user/limited-connectivity/index.rst:218 msgid "" "4. The maximum length of ``no_proxy`` should not exceed 1024 characters due " "to a fixed size buffer in the ``pam_env`` PAM module. Longer environment " "variables will be truncated during deployment operations and this will lead " "to unpredictable errors during or after deployment." msgstr "" #: ../../source/user/limited-connectivity/index.rst:223 msgid "" "Once the number of hosts/containers in a deployment reaches a certain size, " "the length of ``no_proxy`` will exceed 1024 characters at which point it is " "mandatory to use the transient proxy settings which only requires a subset " "of the management network IP addresses to be present in ``no_proxy`` at " "deployment time." msgstr "" #: ../../source/user/limited-connectivity/index.rst:229 msgid "" "Refer to `global_environment_variables:` and " "`deployment_environment_variables:` in the example `user_variables.yml` for " "details of configuring persistent and transient proxy environment variables." msgstr "" #: ../../source/user/limited-connectivity/index.rst:234 msgid "Deployment host proxy configuration for bootstrapping Ansible" msgstr "" #: ../../source/user/limited-connectivity/index.rst:236 msgid "" "Configure the ``bootstrap-ansible.sh`` script used to install Ansible and " "Ansible role dependencies on the deployment host to use a proxy by setting " "the environment variables ``HTTPS_PROXY`` or ``HTTP_PROXY``." msgstr "" #: ../../source/user/limited-connectivity/index.rst:242 msgid "" "We recommend you set your ``/etc/environment`` variables with proxy settings " "before launching any scripts or playbooks to avoid failure." msgstr "" #: ../../source/user/limited-connectivity/index.rst:245 msgid "" "For larger or complex environments a dedicated deployment host allows the " "most suitable proxy configuration to be applied to both deployment and " "target hosts." msgstr "" #: ../../source/user/limited-connectivity/index.rst:249 msgid "Considerations when proxying TLS traffic" msgstr "" #: ../../source/user/limited-connectivity/index.rst:251 msgid "" "Proxying TLS traffic often interferes with the clients ability to perform " "successful validation of the certificate chain. Various configuration " "variables exist within the OpenStack-Ansible playbooks and roles that allow " "a deployer to ignore these validation failures. Disable certificate chain " "validation on a case by case basis and only after encountering failures that " "are known to only be caused by the proxy server(s)." msgstr "" #: ../../source/user/messaging/messaging.rst:3 msgid "Hybrid messaging example" msgstr "" #: ../../source/user/messaging/messaging.rst:5 msgid "" "This section provides an overview of hybrid messaging deployment concepts " "and describes the necessary steps for a working OpenStack-Ansible (OSA) " "deployment where RPC and Notify communications are separated and integrated " "with different messaging server backends (e.g. rabbitmq and qdrouterd)." msgstr "" #: ../../source/user/messaging/messaging.rst:12 msgid "oslo.messaging library" msgstr "" #: ../../source/user/messaging/messaging.rst:14 msgid "" "The oslo.messaging library is part of the OpenStack Oslo project that " "provides intra-service messaging capabilities. The library supports two " "communication patterns (RPC and Notify) and provides an abstraction that " "hides the details of the messaging bus operation from the OpenStack services." "" msgstr "" #: ../../source/user/messaging/messaging.rst:21 msgid "Notifications" msgstr "" #: ../../source/user/messaging/messaging.rst:23 msgid "" "Notify communications are an asynchronous exchange from notifier to listener." " The messages transferred typically correspond to information updates or " "event occurrences that are published by an OpenStack service. The listener " "need not be present when the notification is sent as notify communications " "are temporally decoupled. This decoupling between notifier and listener " "requires that the messaging backend deployed for notifications provide " "message persistence such as a broker queue or log store. It is noteworthy " "that the message transfer is unidirectional from notifier to listener and " "there is no message flow back to the notifier." msgstr "" #: ../../source/user/messaging/messaging.rst:35 msgid "RPC" msgstr "" #: ../../source/user/messaging/messaging.rst:37 msgid "" "The RPC is intended as a synchronous exchange between a client and server " "that is temporally bracketed. The information transferred typically " "corresponds to a request-response pattern for service command invocation. If " "the server is not present at the time the command is invoked, the call " "should fail. The temporal coupling requires that the messaging backend " "deployed support the bi-directional transfer of the request from caller to " "server and the associated reply sent from the server back to the caller. " "This requirement can be satisfied by a broker queue or a direct messaging " "backend server." msgstr "" #: ../../source/user/messaging/messaging.rst:49 msgid "Messaging transport" msgstr "" #: ../../source/user/messaging/messaging.rst:51 msgid "" "The oslo.messaging library supports a messaging `transport plugin`_ " "capability such that RPC and Notify communications can be separated and " "different messaging backend servers can be deployed." msgstr "" #: ../../source/user/messaging/messaging.rst:57 msgid "" "The oslo.messaging drivers provide the transport integration for the " "selected protocol and backend server. The following table summarizes the " "supported oslo.messaging drivers and the communication services they support." "" msgstr "" #: ../../source/user/messaging/messaging.rst:78 msgid "Standard deployment of rabbitmq server" msgstr "" #: ../../source/user/messaging/messaging.rst:80 msgid "" "A single rabbitmq server backend (e.g. server or cluster) is the default " "deployment for OSA. This broker messaging backend provides the queue " "services for both RPC and Notification communications through its " "integration with the oslo.messaging rabbit driver. The `oslo-messaging.yml`_ " "file provides the default configuration to associate the oslo.messaging RPC " "and Notify services to the rabbitmq server backend." msgstr "" #: ../../source/user/messaging/messaging.rst:95 msgid "Hybrid messaging deployment with qdrouterd server" msgstr "" #: ../../source/user/messaging/messaging.rst:97 msgid "" "In OSA, the deployment of disparate messaging backends is completely " "transparent to the OpenStack services. By managing the inventories for the " "messaging servers, a hybrid messaging configuration will be created. The " "instantiation of the qdrouterd server role in the qdrouterd_host_group will " "automatically setup the oslomsg_rpc* variables to use this messaging backend." " No additional configuration is required. The result is that RPC services " "will communicate via the amqp (V1.0 protocol) driver and the Notify services " "will communicate via the rabbit driver. The separation and use of different " "messaging backends can provide increased scale and resiliency." msgstr "" #: ../../source/user/multiarch/multiarch.rst:3 msgid "Multi-Architecture Deployments" msgstr "" #: ../../source/user/multiarch/multiarch.rst:5 msgid "" "OpenStack-Ansible supports deployments where either the control plane or " "compute nodes may comprise of several different CPU architectures" msgstr "" #: ../../source/user/multiarch/multiarch.rst:9 msgid "Mixed CPU architectures for compute nodes" msgstr "" #: ../../source/user/multiarch/multiarch.rst:11 msgid "" "OpenStack-Ansible supports having compute nodes of multiple architectures " "deployed in the same environment." msgstr "" #: ../../source/user/multiarch/multiarch.rst:14 msgid "" "Deployments consisting entirely of x86_64 or aarch64 nodes do not need any " "special consideration and will work according to the normal OpenStack-" "Ansible documentation." msgstr "" #: ../../source/user/multiarch/multiarch.rst:18 msgid "" "A deployment with a mixture of architectures, or adding a new architecture " "to an existing single architecure deployment requires some additional steps " "to be taken by both the deployer and end users to ensure that the behaviour " "is as desired." msgstr "" #: ../../source/user/multiarch/multiarch.rst:24 msgid "Example - adding ``aarch64`` nodes to an ``x86_64`` deployment" msgstr "" #: ../../source/user/multiarch/multiarch.rst:26 msgid "Install the operating system onto all the new compute nodes." msgstr "" #: ../../source/user/multiarch/multiarch.rst:28 msgid "Add the new compute nodes to ``openstack_user_config.yml``." msgstr "" #: ../../source/user/multiarch/multiarch.rst:30 msgid "" "Ensure a host of each compute architecture is present in ``repo-" "infra_hosts`` in ``openstack_user_config.yml``." msgstr "" #: ../../source/user/multiarch/multiarch.rst:33 msgid "" "This host will build python wheels for it's own architecture which will " "speed up the deployment of many hosts. If you do not make a repository " "server for each architecture, ensure that measures are taken not to overload " "the opendev.org git servers, such as using local mirrors of all OpenStack " "service repos." msgstr "" #: ../../source/user/multiarch/multiarch.rst:39 msgid "Run the OpenStack-Ansible playbooks to deploy the required services." msgstr "" #: ../../source/user/multiarch/multiarch.rst:41 msgid "Add HW_ARCH_XXXX Trait to Every Compute Host in Openstack" msgstr "" #: ../../source/user/multiarch/multiarch.rst:43 msgid "" "Although most CPU hardware traits such as instruction set extensions are " "detected and handled automatically in OpenStack, CPU architecture is not. It " "is necessary to manually add an architecture trait to the resource provider " "corresponding to every compute host. The required traits are:" msgstr "" #: ../../source/user/multiarch/multiarch.rst:48 msgid "" "HW_ARCH_X86_64 for x86_64 Intel and AMD CPUs HW_ARCH_AARCH64 for " "aarch64 architecure CPUs" msgstr "" #: ../../source/user/multiarch/multiarch.rst:51 msgid "" "(see: https://docs.openstack.org/os-traits/latest/reference/traits.html)" msgstr "" #: ../../source/user/multiarch/multiarch.rst:61 msgid "" "The trait set command replaces all existing traits with the set provided, so " "you must specify all existing traits as well as the new trait." msgstr "" #: ../../source/user/multiarch/multiarch.rst:64 msgid "Configure Nova Scheduler to Check Architecture" msgstr "" #: ../../source/user/multiarch/multiarch.rst:66 msgid "" "Two additional settings in /etc/nova/nova.conf in all Nova API instances:" msgstr "" #: ../../source/user/multiarch/multiarch.rst:76 msgid "" "The ``image_metadata_prefilter`` setting forces the Nova scheduler to match " "the ``hw_architecture`` property on Glance images with the corresponding " "HW_ARCH_XXX trait on compute host resource providers. This ensures that " "images explicitly tagged with a target architecture get scheduled hosts with " "a matching architecture." msgstr "" #: ../../source/user/multiarch/multiarch.rst:81 msgid "" "The ``image_properties_default_architecture`` setting would apply in an " "existing ``x86_64`` architecture cloud where previously ``hw_architecture`` " "was not set on all Glance images. This avoids the need to retrospectively " "apply the property for all existing images which may be difficult as users " "may have their own tooling to create and upload images without applying the " "required property." msgstr "" #: ../../source/user/multiarch/multiarch.rst:89 msgid "Undocumented Behaviour Alert!" msgstr "" #: ../../source/user/multiarch/multiarch.rst:91 msgid "" "Note that the image metadata prefilter and ImagePropertiesFilter are " "different and unrelated steps in the process Nova scheduler uses to " "determine candidate compute hosts. This section explains how to use them " "together." msgstr "" #: ../../source/user/multiarch/multiarch.rst:95 msgid "" "The ``image_metadata_prefilter`` only looks at the HW_ARCH_XXX traits on " "compute hosts and finds hardware that matches the required architecture. " "This only happens when the ``hw_architecture`` property is present on an " "image, and only if the required traits are manually added to compute hosts." msgstr "" #: ../../source/user/multiarch/multiarch.rst:100 msgid "" "The ``image_properties_default_architecture`` is used by the " "ImagePropertiesFilter which examines all the architectures supported by QEMU " "on each compute host; this includes software emulations of non-native " "architectures." msgstr "" #: ../../source/user/multiarch/multiarch.rst:104 msgid "" "If the full QEMU suite is installed on a compute host, that host will offer " "to run all architectures supported by the available ``qemu-system-*`` " "binaries. In this situation images without the ``hw_architecture`` property " "could be scheduled to a non native architecture host and emulated." msgstr "" #: ../../source/user/multiarch/multiarch.rst:109 msgid "Disable QEMU Emulation" msgstr "" #: ../../source/user/multiarch/multiarch.rst:113 msgid "" "This step applies particularly to existing ``x86_64`` environments when new " "``aarch64`` compute nodes are added and it cannot be assumed that the " "``hw_architecure`` property is applied to all Glance images as the operator " "may not be in control of all image uploads." msgstr "" #: ../../source/user/multiarch/multiarch.rst:118 msgid "" "To avoid unwanted QEMU emulation of non native architectures it is necessary " "to ensure that only the native ``qemu-system-*`` binary is present on all " "compute nodes. The simplest way to do this for existing deployments is to " "use the system package manager to ensure that the unwanted binaries are " "removed." msgstr "" #: ../../source/user/multiarch/multiarch.rst:123 msgid "" "OpenStack-Ansible releases including 2023.1 and later will only install the " "native architecture `qemu-system-*`` binary so this step should not be " "required on newer releases." msgstr "" #: ../../source/user/multiarch/multiarch.rst:127 msgid "Upload images to Glance" msgstr "" #: ../../source/user/multiarch/multiarch.rst:129 msgid "" "Ideally the ``hw_architecture`` property is set for all uploaded images. It " "is mandatory to set this property for all architectures that do not match " "``image_properties_default_architecture``" msgstr "" #: ../../source/user/multiarch/multiarch.rst:133 msgid "" "It is recommended to set the property ``hw_firmware_type='uefi'`` for any " "images which require UEFI boot, even when this implicit with the ``aarch64`` " "architecture. This is to avoid issues with NVRAM files in libvirt when " "deleting an instance." msgstr "" #: ../../source/user/multiarch/multiarch.rst:138 msgid "Architecture emulation by Nova" msgstr "" #: ../../source/user/multiarch/multiarch.rst:140 msgid "" "Nova has the capability to allow emulation of one CPU architecture on a host " "with a different native CPU architecure, see https://docs.openstack.org/nova/" "latest/admin/hw-emulation-architecture.html for more details." msgstr "" #: ../../source/user/multiarch/multiarch.rst:144 msgid "" "This OpenStack-Ansible documentation currently assumes that a deployer " "wishes to run images on a compute host with a native CPU architecure, and " "does not give an example configuration involving emulation." msgstr "" #: ../../source/user/network-arch/example.rst:5 msgid "Network architectures" msgstr "" #: ../../source/user/network-arch/example.rst:7 msgid "" "OpenStack-Ansible supports a number of different network architectures, and " "can be deployed using a single network interface for non-production " "workloads or using multiple network interfaces or bonded interfaces for " "production workloads." msgstr "" #: ../../source/user/network-arch/example.rst:12 msgid "" "The OpenStack-Ansible reference architecture segments traffic using VLANs " "across multiple network interfaces or bonds. Common networks used in an " "OpenStack-Ansible deployment can be observed in the following table:" msgstr "" #: ../../source/user/network-arch/example.rst:21 msgid "Overlay Network" msgstr "" #: ../../source/user/network-arch/example.rst:26 msgid "" "The ``Management Network``, also referred to as the ``container network``, " "provides management of and communication between the infrastructure and " "OpenStack services running in containers or on metal. The ``management " "network`` uses a dedicated VLAN typically connected to the ``br-mgmt`` " "bridge, and may also be used as the primary interface used to interact with " "the server via SSH." msgstr "" #: ../../source/user/network-arch/example.rst:33 msgid "" "The ``Overlay Network``, also referred to as the ``tunnel network``, " "provides connectivity between hosts for the purpose of tunnelling " "encapsulated traffic using VXLAN, GENEVE, or other protocols. The ``overlay " "network`` uses a dedicated VLAN typically connected to the ``br-vxlan`` " "bridge." msgstr "" #: ../../source/user/network-arch/example.rst:39 msgid "" "The ``Storage Network`` provides segregated access to Block Storage from " "OpenStack services such as Cinder and Glance. The ``storage network`` uses a " "dedicated VLAN typically connected to the ``br-storage`` bridge." msgstr "" #: ../../source/user/network-arch/example.rst:45 msgid "" "The CIDRs and VLANs listed for each network are examples and may be " "different in your environment." msgstr "" #: ../../source/user/network-arch/example.rst:48 msgid "Additional VLANs may be required for the following purposes:" msgstr "" #: ../../source/user/network-arch/example.rst:50 msgid "External provider networks for Floating IPs and instances" msgstr "" #: ../../source/user/network-arch/example.rst:51 msgid "Self-service project/tenant networks for instances" msgstr "" #: ../../source/user/network-arch/example.rst:52 msgid "Other OpenStack services" msgstr "" #: ../../source/user/network-arch/example.rst:55 msgid "Network interfaces" msgstr "" #: ../../source/user/network-arch/example.rst:58 msgid "Configuring network interfaces" msgstr "" #: ../../source/user/network-arch/example.rst:60 msgid "" "OpenStack-Ansible does not mandate any specific method of configuring " "network interfaces on the host. You may choose any tool, such as ifupdown, " "netplan, systemd-networkd, networkmanager or another operating-system " "specific tool. The only requirement is that a set of functioning network " "bridges and interfaces are created which match those expected by OpenStack-" "Ansible, plus any that you choose to specify for neutron physical interfaces." "" msgstr "" #: ../../source/user/network-arch/example.rst:68 msgid "" "A selection of network configuration example files are given in the ``etc/" "network`` and ``etc/netplan`` for ubuntu systems, and it is expected that " "these will need adjustment for the specific requirements of each deployment." msgstr "" #: ../../source/user/network-arch/example.rst:73 msgid "" "If you want to delegate management of network bridges and interfaces to " "OpenStack-Ansible, you can define variables " "``openstack_hosts_systemd_networkd_devices`` and " "``openstack_hosts_systemd_networkd_networks`` in `group_vars/lxc_hosts`, for " "example:" msgstr "" #: ../../source/user/network-arch/example.rst:111 msgid "" "If you need to run some pre/post hooks for interfaces, you will need to " "configure a systemd service for that. It can be done using variable " "``openstack_hosts_systemd_services``, like that:" msgstr "" #: ../../source/user/network-arch/example.rst:132 msgid "Single interface or bond" msgstr "" #: ../../source/user/network-arch/example.rst:134 msgid "" "OpenStack-Ansible supports the use of a single interface or set of bonded " "interfaces that carry traffic for OpenStack services as well as instances." msgstr "" #: ../../source/user/network-arch/example.rst:139 #: ../../source/user/network-arch/example.rst:197 msgid "Open Virtual Network (OVN)" msgstr "" #: ../../source/user/network-arch/example.rst:141 msgid "The following diagrams demonstrate hosts using a single bond with OVN." msgstr "" #: ../../source/user/network-arch/example.rst:143 #: ../../source/user/network-arch/example.rst:201 msgid "" "In the scenario below only Network node is connected to external network and " "computes do not have external connectivity, so routers are needed for " "external connectivity:" msgstr "" #: ../../source/user/network-arch/example.rst:152 #: ../../source/user/network-arch/example.rst:210 msgid "" "The following diagram demonstrates a compute node serving as an OVN gatway. " "It is connected to the public network, which enables to connect VMs to " "public networks not only through routers, but also directly:" msgstr "" #: ../../source/user/network-arch/example.rst:162 #: ../../source/user/network-arch/example.rst:220 msgid "Open vSwitch and Linux Bridge" msgstr "" #: ../../source/user/network-arch/example.rst:164 msgid "" "The following diagram demonstrates hosts using a single interface for OVS " "and LinuxBridge Scenario:" msgstr "" #: ../../source/user/network-arch/example.rst:171 msgid "The following diagram demonstrates hosts using a single bond:" msgstr "" #: ../../source/user/network-arch/example.rst:177 msgid "" "Each host will require the correct network bridges to be implemented. The " "following is the ``/etc/network/interfaces`` file for ``infra1`` using a " "single bond." msgstr "" #: ../../source/user/network-arch/example.rst:191 msgid "Multiple interfaces or bonds" msgstr "" #: ../../source/user/network-arch/example.rst:193 msgid "" "OpenStack-Ansible supports the use of a multiple interfaces or sets of " "bonded interfaces that carry traffic for OpenStack services and instances." msgstr "" #: ../../source/user/network-arch/example.rst:199 msgid "" "The following diagrams demonstrate hosts using multiple bonds with OVN." msgstr "" #: ../../source/user/network-arch/example.rst:222 msgid "" "The following diagram demonstrates hosts using multiple interfaces for OVS " "and LinuxBridge Scenario:" msgstr "" #: ../../source/user/network-arch/example.rst:229 msgid "The following diagram demonstrates hosts using multiple bonds:" msgstr "" #: ../../source/user/network-arch/example.rst:235 msgid "" "Each host will require the correct network bridges to be implemented. The " "following is the ``/etc/network/interfaces`` file for ``infra1`` using " "multiple bonded interfaces." msgstr "" #: ../../source/user/network-arch/example.rst:249 msgid "Additional resources" msgstr "" #: ../../source/user/network-arch/example.rst:251 msgid "" "For more information on how to properly configure network interface files " "and OpenStack-Ansible configuration files for different deployment " "scenarios, please refer to the following:" msgstr "" #: ../../source/user/network-arch/example.rst:255 msgid ":dev_docs:`Configuring a test environment `" msgstr "" #: ../../source/user/network-arch/example.rst:257 msgid "" ":dev_docs:`Configuring a homogeneous production environment `" msgstr "" #: ../../source/user/network-arch/example.rst:259 msgid "" ":dev_docs:`Using provider network groups for a heterogeneous environment " "`" msgstr "" #: ../../source/user/network-arch/example.rst:262 msgid "" "For network agent and container networking toplogies, please refer to the " "following:" msgstr "" #: ../../source/user/network-arch/example.rst:265 msgid "" ":dev_docs:`Container networking architecture `" msgstr "" #: ../../source/user/network-arch/example.rst:-1 msgid "Network Interface Layout - Multiple Bonds" msgstr "" #: ../../source/user/network-arch/example.rst:-1 msgid "Network Interface Layout - Multiple Interfaces" msgstr "" #: ../../source/user/network-arch/example.rst:-1 msgid "Network Interface Layout - Single Bond" msgstr "" #: ../../source/user/network-arch/example.rst:-1 msgid "Network Interface Layout - Single Interface" msgstr "" #: ../../source/user/network-arch/example.rst:-1 msgid "Network Interface Layout OVN - Gateway Nodes" msgstr "" #: ../../source/user/prod/example.rst:5 msgid "Production environment" msgstr "" #: ../../source/user/prod/example.rst:7 msgid "" "This is an example production environment for a working OpenStack-Ansible " "(OSA) deployment with high availability services." msgstr "" #: ../../source/user/prod/example.rst:18 msgid "" "Full compute kit with the Telemetry service (ceilometer) included, with NFS " "configured as a storage back end for the Image (glance), and Block Storage " "(cinder) services" msgstr "" #: ../../source/user/prod/example.rst:-1 #: ../../source/user/prod/provnet_groups.rst:-1 msgid "Production environment host layout" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:3 msgid "Telemetry with Gnocchi, Ceph and Redis example" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:5 msgid "" "The default openstack-ansible installation configures gnocchi to use a file " "as storage backend. When you already have a pre-installed ceph, you can use " "this as backend for gnocchi. This documentation will guide you how to set up " "gnocchi to use your ceph as storage backend." msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:11 msgid "Ceph as metric storage" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:17 msgid "You have to add some pip packages to your gnocchi setup:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:33 msgid "" "But when your setup grows, gnocchi might slow down or block your ceph " "installation. You might experience slow requests and stuck PGs in your Ceph. " "As this might have multiple causes, take a look at the presentations linked " "in the `Performance Tests for Gnocchi`_ section. They also include various " "parameters which you might tune." msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:40 msgid "Redis as measure storage" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:42 msgid "" "One solution to possible performance problems is to use an incoming measure " "storage for your gnocchi installation. The `supported storage systems`_ are:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:45 msgid "File (default)" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:46 msgid "Ceph (preferred)" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:47 msgid "OpenStack Swift" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:48 msgid "Amazon S3" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:49 msgid "Redis" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:53 msgid "" "When your Swift API endpoint uses Ceph as a backend, the only one left for " "this setup is Redis." msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:56 msgid "" "So first of all setup a redis server/cluster, e.g. with this `ansible role`_." " Next, you have to configure Gnocchi with OpenStack-Ansible to use the Redis " "Cluster as incoming storage:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:69 msgid "" "You also have to install additional pip/distro packages to use the redis " "cluster:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:106 msgid "" "A word of caution: the name of the Ceph alternative lib implementation " "(ceph_alternative_lib) varies between Gnocchi versions." msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:109 msgid "Zookeeper for coordination" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:111 msgid "" "When you deployed Gnocchi on multiple servers to distribute the work, add " "Zookeeper as coordination backend. To setup Zookeeper, you can use `this " "ansible role`_." msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:117 msgid "Create containers for Zookeeper:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:146 msgid "Now you can set up Zookeeper as coordination backend for Gnocchi:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:152 msgid "You also have to install additional packages:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:175 msgid "Performance Tests for Gnocchi" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:177 msgid "" "For more ideas how to tune your Gnocchi stack, take a look at these " "presentations:" msgstr "" #: ../../source/user/prod/gnocchi_redis.rst:180 msgid "" "https://docs.openstack.org/performance-docs/test_results/" "telemetry_gnocchi_with_ceph/index.html" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:3 msgid "HAProxy and Keepalived in LXC containers" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:5 msgid "" "There can be a usecase where you might want to run HAProxy and Keepalived " "inside LXC containers. For instance, running these services on bare metal " "assumes that a default route for hosts should be set towards a public " "network. This scenario might be un-preferable for some deployments, " "especially in cases where you do not have standalone Load-Balancing hosts, " "but they're co-located with other infra services instead." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:14 msgid "Inventory overrides" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:16 msgid "" "In order to tell dynamic_inventory to generate a set of containers for " "haproxy, you need to create a file ``/etc/openstack_deploy/env.d/haproxy." "yml`` with the following content:" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:29 msgid "Defining host networking" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:31 msgid "" "In order to make a public network available, you need to ensure having a " "corresponsive bridge on your hosts to which HAProxy containers will be " "plugged in with one side of a veth pair. The bridge should also contain a " "VLAN interface providing \"public\" connectivity." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:37 msgid "" "You can create a bridge manually or leverage our systemd_networkd role which " "is capable of configuring required networking on hosts." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:40 msgid "" "For the example below, let's name our bridge ``br-public-api`` and public " "vlan with ID ``40``. In your ``user_variables.yml`` define the following " "variables:" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:121 msgid "Defining container networking" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:123 msgid "" "In case of deploying HAProxy inside LXC you need to ensure connectivity with " "a public network and that ``haproxy_bind_external_lb_vip_address`` will be " "present inside the container as well as ``external_lb_vip_address`` is " "reachable." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:128 msgid "" "For that we need to do the following series of changes in the " "``openstack_user_config.yml`` file." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:131 msgid "" "In ``cidr_networks`` add a network which should be used as \"public\" " "network for accessing APIs. For example we will be using `203.0.113.128/28`:" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:140 msgid "" "In ``used_ips`` you need to reserve IP address for your gateway and " "``haproxy_keepalived_external_vip_cidr``/``external_lb_vip_address``" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:151 msgid "" "In ``provider_networks`` you need to define a new container network and " "assign it to HAproxy group." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:172 msgid "" "While these are all changes, that need to be done in ``openstack_user_config." "yml``, there is one more override that needs to be applied." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:176 msgid "" "As you might have spotted, we are defining a default route for the container " "through eth20. However, by default all containers have their default route " "through eth0, which is a local LXC bridge where address is recieved through " "DHCP. In order to avoid a conflict, you need to ensure that the default " "route will not be set for eth0 inside the container. For that, create a file " "`/etc/openstack_deploy/group_vars/haproxy` with the following content:" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:196 msgid "Configuring HAProxy binding inside containers" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:198 msgid "" "As IP provisioning is quite random inside containers, it may not always be " "handy to bind HAProxy to a specific IP address. If that's the case, you can " "bind HAProxy to an interface instead, since we always know the interface " "names inside containers. With that keepalived public/internal VIPs are " "supposed to be added in ``used_ips``, so you still can define them freely." msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:204 msgid "Example bellow shows a possible content in ``user_variables.yml``:" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:217 msgid "" "Alternatively, you can detect IPs used inside your containers to configure " "haproxy binds. This can be done by reffering to ``container_networks`` " "mapping:" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:227 msgid "Creating containers" msgstr "" #: ../../source/user/prod/haproxy_in_lxc.rst:229 msgid "" "Once all steps above are accomplished, it's time to create our new haproxy " "containers. For that run the following command:" msgstr "" #: ../../source/user/prod/provnet_groups.rst:5 msgid "Provider network groups" msgstr "" #: ../../source/user/prod/provnet_groups.rst:7 msgid "" "Many network configuration examples assume a homogenous environment, where " "each server is configured identically and consistent network interfaces and " "interface names can be assumed across all hosts." msgstr "" #: ../../source/user/prod/provnet_groups.rst:11 msgid "" "Recent changes to OSA enables deployers to define provider networks that " "apply to particular inventory groups and allows for a heterogeneous network " "configuration within a cloud environment. New groups can be created or " "existing inventory groups, such as ``network_hosts`` or ``compute_hosts``, " "can be used to ensure certain configurations are applied only to hosts that " "meet the given parameters." msgstr "" #: ../../source/user/prod/provnet_groups.rst:18 msgid "Before reading this document, please review the following scenario:" msgstr "" #: ../../source/user/prod/provnet_groups.rst:20 msgid ":dev_docs:`Production environment `" msgstr "" #: ../../source/user/prod/provnet_groups.rst:24 msgid "" "A ``network_hosts`` group consisting of three collapsed infrastructure/" "network (control plane) hosts" msgstr "" #: ../../source/user/prod/provnet_groups.rst:26 msgid "A ``compute_hosts`` group consisting of two compute hosts" msgstr "" #: ../../source/user/prod/provnet_groups.rst:27 msgid "" "Multiple Network Interface Cards (NIC) used as provider network interfaces " "that vary between hosts" msgstr "" #: ../../source/user/prod/provnet_groups.rst:32 msgid "" "The groups ``network_hosts`` and ``compute_hosts`` are pre-defined groups in " "an OpenStack-Ansible deployment." msgstr "" #: ../../source/user/prod/provnet_groups.rst:35 msgid "" "The following diagram demonstates servers with different network interface " "names:" msgstr "" #: ../../source/user/prod/provnet_groups.rst:42 msgid "" "In this example environment, infrastructure/network nodes hosting L2/L3/DHCP " "agents will utilize an interface named ``ens1f0`` for the provider network " "``physnet1``. Compute nodes, on the other hand, will utilize an interface " "named ``ens2f0`` for the same ``physnet1`` provider network." msgstr "" #: ../../source/user/prod/provnet_groups.rst:49 msgid "" "Differences in network interface names may be the result of a difference in " "drivers and/or PCI slot locations." msgstr "" #: ../../source/user/prod/provnet_groups.rst:65 msgid "" "Hosts in the ``network_hosts`` group will map ``physnet1`` to the ``ens1f0`` " "interface, while hosts in the ``compute_hosts`` group will map ``physnet1`` " "to the ``ens2f0`` interface. Additional provider mappings can be established " "using the same format in a separate definition." msgstr "" #: ../../source/user/prod/provnet_groups.rst:70 msgid "" "An additional provider interface definition named ``physnet2`` using " "different interfaces between hosts may resemble the following:" msgstr "" #: ../../source/user/prod/provnet_groups.rst:97 msgid "" "The ``container_interface`` parameter is only necessary when Neutron agents " "are run in containers, and can be excluded in many cases. The " "``container_bridge`` and ``container_type`` parameters also relate to " "infrastructure containers, but should remain defined for legacy purposes." msgstr "" #: ../../source/user/prod/provnet_groups.rst:103 msgid "Custom Groups" msgstr "" #: ../../source/user/prod/provnet_groups.rst:105 msgid "" "Custom inventory groups can be created to assist in segmenting hosts beyond " "the built-in groups provided by OpenStack-Ansible." msgstr "" #: ../../source/user/prod/provnet_groups.rst:108 msgid "Before creating custom groups, please review the following:" msgstr "" #: ../../source/user/prod/provnet_groups.rst:110 msgid "" ":dev_docs:`Configuring the inventory `" msgstr "" #: ../../source/user/prod/provnet_groups.rst:113 msgid "" "The following diagram demonstates how a custom group can be used to further " "segment hosts:" msgstr "" #: ../../source/user/prod/provnet_groups.rst:120 msgid "" "When creating a custom group, first create a skeleton in ``/etc/" "openstack_deploy/env.d/``. The following is an example of an inventory " "skeleton for a group named ``custom2_hosts`` that will consist of bare metal " "hosts, and has been created at ``/etc/openstack_deploy/env.d/custom2_hosts." "yml``." msgstr "" #: ../../source/user/prod/provnet_groups.rst:137 msgid "" "Define the group and its members in a corresponding file in ``/etc/" "openstack_deploy/conf.d/``. The following is an example of a group named " "``custom2_hosts`` defined in ``/etc/openstack_deploy/conf.d/custom2_hosts." "yml`` consisting of a single member, ``compute2``:" msgstr "" #: ../../source/user/prod/provnet_groups.rst:151 msgid "" "The custom group can then be specifed when creating a provider network, as " "shown here:" msgstr "" #: ../../source/user/security/hardening.rst:2 msgid "Apply ansible-hardening" msgstr "" #: ../../source/user/security/hardening.rst:4 msgid "" "The ``ansible-hardening`` role is applicable to physical hosts within an " "OpenStack-Ansible deployment that are operating as any type of node, " "infrastructure or compute. By default, the role is enabled. You can disable " "it by changing the value of the ``apply_security_hardening`` variable in the " "``user_variables.yml`` file to ``false``:" msgstr "" #: ../../source/user/security/hardening.rst:15 msgid "" "You can apply security hardening configurations to an existing environment " "or audit an environment by using a playbook supplied with OpenStack-Ansible:" msgstr "" #: ../../source/user/security/hardening.rst:26 msgid "" "For more information about the security configurations, see the `security " "hardening role`_ documentation." msgstr "" #: ../../source/user/security/index.rst:5 msgid "Security settings" msgstr "" #: ../../source/user/security/index.rst:7 msgid "" "This chapter contains information to configure specific security settings " "for your OpenStack-Ansible cloud." msgstr "" #: ../../source/user/security/index.rst:10 msgid "For understanding security design, please see :ref:`security-design`." msgstr "" #: ../../source/user/security/non-root.rst:2 msgid "Running as non-root user" msgstr "" #: ../../source/user/security/non-root.rst:4 msgid "" "Deployers do not have to use ``root`` user accounts on deploy or target " "hosts. This approach works out of the box by leveraging `Ansible privilege " "escalation`_." msgstr "" #: ../../source/user/security/non-root.rst:9 msgid "Deploment hosts" msgstr "" #: ../../source/user/security/non-root.rst:11 msgid "" "You can avoid usage of the ``root`` user on a deployment by following these " "guidelines:" msgstr "" #: ../../source/user/security/non-root.rst:14 msgid "" "Clone OpenStack-Ansible repository to home user directory. It means, that " "instead of ``/opt/openstack-ansible`` repository will be in ``~/openstack-" "ansible``." msgstr "" #: ../../source/user/security/non-root.rst:18 msgid "" "Use custom path for ``/etc/openstack_deploy`` directory. You can place " "OpenStack-Ansible configuration directory inside user home directory. For " "that you will need to define the following environment variable:" msgstr "" #: ../../source/user/security/non-root.rst:26 msgid "" "If you want to keep basic ansible logging, you need either to create ``/" "openstack/log/ansible-logging/`` directory and allow user to write there, or " "define the following environment variable:" msgstr "" #: ../../source/user/security/non-root.rst:36 msgid "" "You can also add the environment variable to ``user.rc`` file inside " "openstack_deploy folder (``${OSA_CONFIG_DIR}/user.rc``). ``user.rc`` file is " "sourced each time you run ``openstack-ansible`` binary." msgstr "" #: ../../source/user/security/non-root.rst:40 msgid "" "Initial bootstrap of OpenStack-Ansible using ./scripts/bootstrap-ansible.sh " "script still should be done either as the ``root`` user or escalate " "privileges using ``sudo`` or ``su``." msgstr "" #: ../../source/user/security/non-root.rst:46 msgid "Destination hosts" msgstr "" #: ../../source/user/security/non-root.rst:48 msgid "" "It is also possible to use non-root user for Ansible authentication on " "destination hosts. However, this user must be able to escalate privileges " "using `Ansible privilege escalation`_." msgstr "" #: ../../source/user/security/non-root.rst:54 msgid "" "You can add environment variables from that section to ``user.rc`` file " "inside openstack_deploy folder (``${OSA_CONFIG_DIR}/user.rc``). ``user.rc`` " "file is sourced each time you run ``openstack-ansible`` binary." msgstr "" #: ../../source/user/security/non-root.rst:58 msgid "" "There are also couple of additional things which you might want to consider:" msgstr "" #: ../../source/user/security/non-root.rst:60 msgid "" "Provide ``--become`` flag each time your run a playbook or ad-hoc command. " "Alternatively, you can define the following environment variable:" msgstr "" #: ../../source/user/security/non-root.rst:68 msgid "" "Override Ansible temporary path if LXC containers are used. The ansible " "connection from the physical host to the LXC container passes environment " "variables from the host. This means that Ansible attempts to use the same " "temporary folder in the LXC container as it would on the host, relative to " "the non-root user ${HOME} directory. This will not exist inside the " "container and another path must be used instead." msgstr "" #: ../../source/user/security/non-root.rst:75 msgid "You can do that following in multiple ways:" msgstr "" #: ../../source/user/security/non-root.rst:77 msgid "Define ``ansible_remote_tmp: /tmp`` in user_variables.yml" msgstr "" #: ../../source/user/security/non-root.rst:78 #: ../../source/user/security/non-root.rst:89 msgid "Define the following environment variable:" msgstr "" #: ../../source/user/security/non-root.rst:84 msgid "" "Define the user that will be used for for connections from the deploy host " "to the ansible target hosts. In case the user is the same for all hosts in " "your deployment, you can do it in one of following ways:" msgstr "" #: ../../source/user/security/non-root.rst:88 msgid "Define ``ansible_user: `` in user_variables.yml" msgstr "" #: ../../source/user/security/non-root.rst:95 msgid "" "If the user differs from host to host, you can leverage group_vars or " "host_vars. More information on how to use that can be found in the :doc:" "`overrides guide `" msgstr "" #: ../../source/user/security/security-headers.rst:2 msgid "Security Headers" msgstr "" #: ../../source/user/security/security-headers.rst:4 msgid "" "Security headers are HTTP headers that can be used to increase the security " "of a web application by restricting what modern browsers are able to run." msgstr "" #: ../../source/user/security/security-headers.rst:7 msgid "" "In OpenStack-Ansible, security headers are implemented in haproxy as all the " "public endpoints reside behind it." msgstr "" #: ../../source/user/security/security-headers.rst:10 msgid "" "The following headers are enabled by default on all the haproxy interfaces " "that implement TLS, but only for the Horizon service. The security headers " "can be implemented on other haproxy services, but only services used by " "browsers will make use of the headers." msgstr "" #: ../../source/user/security/security-headers.rst:16 msgid "HTTP Strict Transport Security" msgstr "" #: ../../source/user/security/security-headers.rst:18 msgid "" "The `OpenStack TLS Security Guide`_ recommends that all production " "deployments use HTTP strict transport security (HSTS)." msgstr "" #: ../../source/user/security/security-headers.rst:23 msgid "" "By design, this header is difficult to disable once set. It is recommended " "that during testing you set a short time of 1 day and after testing increase " "the time to 1 year." msgstr "" #: ../../source/user/security/security-headers.rst:27 msgid "" "To change the default max age to 1 day, override the variable " "``haproxy_security_headers_max_age`` in the ``/etc/openstack_deploy/" "user_variables.yml`` file:" msgstr "" #: ../../source/user/security/security-headers.rst:35 msgid "" "If you would like your domain included in the HSTS preload list, which is " "built into browsers, before submitting your request to be added to the HSTS " "preload list you must add the ``preload`` token to your response header. The " "``preload`` token indicates to the maintainers of HSTS preload list that you " "are happy to have your site included." msgstr "" #: ../../source/user/security/security-headers.rst:46 msgid "X-Content-Type-Options" msgstr "" #: ../../source/user/security/security-headers.rst:48 msgid "The ``X-Content-Type-Options`` header prevents MIME type sniffing." msgstr "" #: ../../source/user/security/security-headers.rst:50 #: ../../source/user/security/security-headers.rst:61 #: ../../source/user/security/security-headers.rst:75 msgid "" "This functionality can be changed by overriding the list of headers in " "``haproxy_security_headers`` variable in the ``/etc/openstack_deploy/" "user_variables.yml`` file." msgstr "" #: ../../source/user/security/security-headers.rst:55 msgid "Referrer Policy" msgstr "" #: ../../source/user/security/security-headers.rst:57 msgid "" "The ``Referrer-Policy`` header controls how much referrer information is " "sent with requests. It defaults to ``same-origin``, which does not send the " "origin path for cross-origin requests." msgstr "" #: ../../source/user/security/security-headers.rst:66 msgid "Permission Policy" msgstr "" #: ../../source/user/security/security-headers.rst:68 msgid "" "The ``Permissions-Policy`` header allows you to selectively enable, disable " "or modify the use of browser features and APIs, previously known as Feature " "Policy." msgstr "" #: ../../source/user/security/security-headers.rst:71 msgid "" "By default this header is set to block access to all features apart from the " "following from the same origin; fullscreen, clipboard read, clipboard write " "and spatial navigation." msgstr "" #: ../../source/user/security/security-headers.rst:81 msgid "Content Security Policy (CSP)" msgstr "" #: ../../source/user/security/security-headers.rst:83 msgid "" "The ``Content-Security-Policy`` header allows you to control what resources " "a browser is allowed to load for a given page, which helps to mitigate the " "risks from Cross-Site Scripting (XSS) and data injection attacks." msgstr "" #: ../../source/user/security/security-headers.rst:87 msgid "" "By default, the Content Security Policy (CSP) enables a minimum set of " "resources to allow Horizon to work, which includes access the Nova console. " "If you require access to other resources these can be set by overriding the " "``haproxy_security_headers_csp`` variable in the ``/etc/openstack_deploy/" "user_variables.yml`` file." msgstr "" #: ../../source/user/security/security-headers.rst:94 msgid "Report Only" msgstr "" #: ../../source/user/security/security-headers.rst:96 msgid "" "Implementing CSP could lead to broken content if a browser is blocked from " "accessing certain resources, therefore it is recommended that when testing " "CSP you use the ``Content-Security-Policy-Report-Only`` header, instead of " "``Content-Security-Policy``, this reports CSP violations to the browser " "console, but does not enforce the policy." msgstr "" #: ../../source/user/security/security-headers.rst:102 msgid "" "To set the CSP policy to report only by overriding the " "``haproxy_security_headers_csp_report_only`` variable to ``True`` in the ``/" "etc/openstack_deploy/user_variables.yml`` file:" msgstr "" #: ../../source/user/security/security-headers.rst:112 msgid "Reporting Violations" msgstr "" #: ../../source/user/security/security-headers.rst:114 msgid "" "It is recommended that you monitor attempted CSP violations in production, " "this is achieved by setting the ``report-uri`` and ``report-to`` tokens." msgstr "" #: ../../source/user/security/security-headers.rst:118 msgid "Federated Login" msgstr "" #: ../../source/user/security/security-headers.rst:120 msgid "" "When using federated login you will need to override the default Content " "Security Policy to allow access to your authorisation server by overriding " "the ``haproxy_horizon_csp`` variable in the ``/etc/openstack_deploy/" "user_variables.yml`` file:" msgstr "" #: ../../source/user/security/security-headers.rst:139 msgid "It is also possible to set specific security headers for skyline." msgstr "" #: ../../source/user/security/security-txt.rst:2 msgid "Security.txt" msgstr "" #: ../../source/user/security/security-txt.rst:4 msgid "" "security.txt is a proposed `IETF standard`_ to allow independent security " "researchers to easily report vulnerabilities. The standard defines that a " "text file called ``security.txt`` should be found at \"/.well-known/security." "txt\". For legacy compatibility reasons the file might also be placed at \"/" "security.txt\"." msgstr "" #: ../../source/user/security/security-txt.rst:11 msgid "" "In OpenStack-Ansible, ``security.txt`` is implemented in haproxy as all " "public endpoints reside behind it. It defaults to directing any request " "paths that end with ``/security.txt`` to the text file using an ACL rule in " "haproxy." msgstr "" #: ../../source/user/security/security-txt.rst:16 msgid "Enabling security.txt" msgstr "" #: ../../source/user/security/security-txt.rst:18 msgid "" "Use the following process to add a ``security.txt`` file to your deployment " "using OpenStack-Ansible:" msgstr "" #: ../../source/user/security/security-txt.rst:21 msgid "" "Write the contents of the ``security.txt`` file in accordance with the " "standard." msgstr "" #: ../../source/user/security/security-txt.rst:23 msgid "" "Define the contents of ``security.txt`` in the variable " "``haproxy_security_txt_content`` in the ``/etc/openstack_deploy/" "user_variables.yml`` file:" msgstr "" #: ../../source/user/security/security-txt.rst:33 msgid "Update haproxy" msgstr "" #: ../../source/user/security/security-txt.rst:40 msgid "Advanced security.txt ACL" msgstr "" #: ../../source/user/security/security-txt.rst:42 msgid "" "In some cases you may need to change the haproxy ACL used to redirect " "requests to the ``security.txt`` file, such as adding extra domains." msgstr "" #: ../../source/user/security/security-txt.rst:45 msgid "" "The haproxy ACL is updated by overriding the variable " "``haproxy_map_entries`` inside ``haproxy_security_txt_service``." msgstr "" #: ../../source/user/security/ssl-certificates.rst:2 msgid "Securing services with SSL certificates" msgstr "" #: ../../source/user/security/ssl-certificates.rst:4 msgid "" "The `OpenStack Security Guide`_ recommends providing secure communication " "between various services in an OpenStack deployment. The OpenStack-Ansible " "project currently offers the ability to configure SSL certificates for " "secure communication between services:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:11 msgid "" "All public endpoints reside behind haproxy, resulting in the only " "certificate management for externally visible https services are those for " "haproxy. Certain internal services such as RabbitMQ also require proper SSL " "configuration." msgstr "" #: ../../source/user/security/ssl-certificates.rst:15 msgid "" "When deploying with OpenStack-Ansible, you can either use self-signed " "certificates that are generated during the deployment process or provide SSL " "certificates, keys, and CA certificates from your own trusted certificate " "authority. Highly secured environments use trusted, user-provided " "certificates for as many services as possible." msgstr "" #: ../../source/user/security/ssl-certificates.rst:23 msgid "" "Perform all SSL certificate configuration in ``/etc/openstack_deploy/" "user_variables.yml`` file. Do not edit the playbooks or roles themselves." msgstr "" #: ../../source/user/security/ssl-certificates.rst:27 msgid "" "Openstack-Ansible uses an ansible role `ansible_role_pki`_ as a general tool " "to manage and install self-signed and user provided certificates." msgstr "" #: ../../source/user/security/ssl-certificates.rst:34 msgid "" "The openstack-ansible example configurations are designed to be minimal " "examples and in test or development use-cases will set " "``external_lb_vip_address`` to the IP address of the haproxy external " "endpoint. For a production deployment it is advised to set " "``external_lb_vip_address`` to be the FQDN which resolves via DNS to the IP " "of the external endpoint." msgstr "" #: ../../source/user/security/ssl-certificates.rst:41 msgid "Self-signed certificates" msgstr "" #: ../../source/user/security/ssl-certificates.rst:43 msgid "" "Self-signed certificates enable you to start quickly and encrypt data in " "transit. However, they do not provide a high level of trust for public " "endpoints in highly secure environments. By default, self-signed " "certificates are used in OpenStack-Ansible. When self-signed certificates " "are used, certificate verification is automatically disabled." msgstr "" #: ../../source/user/security/ssl-certificates.rst:49 msgid "" "Self-signed certificates can play an important role in securing internal " "services within the Openstack-Ansible deployment, as they can only be issued " "by the private CA associated with the deployment. Using mutual TLS between " "backend services such as RabbitMQ and MariaDB with self-signed certificates " "and a robust CA setup can ensure that only correctly authenticated clients " "can connect to these internal services." msgstr "" #: ../../source/user/security/ssl-certificates.rst:57 msgid "Generating and regenerating self-signed certificate authorities" msgstr "" #: ../../source/user/security/ssl-certificates.rst:59 msgid "" "A self-signed certificate authority is generated on the deploy host during " "the first run of the playbook." msgstr "" #: ../../source/user/security/ssl-certificates.rst:62 msgid "" "To regenerate the certificate authority you must set the " "``openstack_pki_regen_ca`` variable to either the name of the root CA or " "intermediate CA you wish or regenerate, or to ``true`` to regenerate all " "self-signed certificate authorities." msgstr "" #: ../../source/user/security/ssl-certificates.rst:71 msgid "" "Take particular care not to regenerate Root or Intermediate certificate " "authorities in a way that may invalidate existing server certificates in the " "deployment. It may be preferable to create new Intermediate CA certificates " "rather than regenerate existing ones in order to maintain existing chains of " "trust." msgstr "" #: ../../source/user/security/ssl-certificates.rst:78 msgid "Generating and regenerating self-signed certificates" msgstr "" #: ../../source/user/security/ssl-certificates.rst:80 msgid "" "Self-signed certificates are generated for each service during the first run " "of the playbook." msgstr "" #: ../../source/user/security/ssl-certificates.rst:83 msgid "" "To regenerate a new self-signed certificate for a service, you must set the " "``_pki_regen_cert`` variable to true in one of the following " "ways:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:87 #: ../../source/user/security/ssl-certificates.rst:143 msgid "" "To force a self-signed certificate to regenerate, you can pass the variable " "to ``openstack-ansible`` on the command line:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:94 msgid "" "To force a self-signed certificate to regenerate with every playbook run, " "set the appropriate regeneration option to ``true``. For example, if you " "have already run the ``haproxy`` playbook, but you want to regenerate the " "self-signed certificate, set the ``haproxy_pki_regen_cert`` variable to " "``true`` in the ``/etc/openstack_deploy/user_variables.yml`` file:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:106 msgid "Generating and regenerating self-signed user certificates" msgstr "" #: ../../source/user/security/ssl-certificates.rst:108 msgid "" "Self-signed user certificates are generated but not installed for services " "outside of Openstack ansible. These user certificates are signed by the same " "self-signed certificate authority as is used by openstack services but are " "intended to be used by user applications." msgstr "" #: ../../source/user/security/ssl-certificates.rst:113 msgid "" "To generate user certificates, define a variable with the prefix " "``user_pki_certificates_`` in the ``/etc/openstack_deploy/user_variables." "yml`` file." msgstr "" #: ../../source/user/security/ssl-certificates.rst:117 msgid "Example" msgstr "" #: ../../source/user/security/ssl-certificates.rst:133 msgid "Generate the certificate with the following command:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:139 msgid "" "To regenerate a new self-signed certificate for a service, you must set the " "``user_pki_regen_cert`` variable to true in one of the following ways:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:150 msgid "" "To force a self-signed certificate to regenerate with every playbook run, " "set the ``user_pki_regen_cert`` variable to ``true`` in the ``/etc/" "openstack_deploy/user_variables.yml`` file:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:160 msgid "User-provided certificates" msgstr "" #: ../../source/user/security/ssl-certificates.rst:162 msgid "" "For added trust in highly secure environments, you can provide your own SSL " "certificates, keys, and CA certificates. Acquiring certificates from a " "trusted certificate authority is outside the scope of this document, but the " "`Certificate Management`_ section of the Linux Documentation Project " "explains how to create your own certificate authority and sign certificates." msgstr "" #: ../../source/user/security/ssl-certificates.rst:170 msgid "" "Use the following process to deploy user-provided SSL certificates in " "OpenStack-Ansible:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:173 msgid "" "Copy your SSL certificate, key, and CA certificate files to the deployment " "host." msgstr "" #: ../../source/user/security/ssl-certificates.rst:175 msgid "" "Specify the path to your SSL certificate, key, and CA certificate in the ``/" "etc/openstack_deploy/user_variables.yml`` file." msgstr "" #: ../../source/user/security/ssl-certificates.rst:177 msgid "Run the playbook for that service." msgstr "" #: ../../source/user/security/ssl-certificates.rst:180 msgid "HAProxy example" msgstr "" #: ../../source/user/security/ssl-certificates.rst:182 msgid "" "The variables to set which provide the path on the deployment node to the " "certificates for HAProxy configuration are:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:192 msgid "RabbitMQ example" msgstr "" #: ../../source/user/security/ssl-certificates.rst:194 msgid "" "To deploy user-provided certificates for RabbitMQ, copy the certificates to " "the deployment host, edit the ``/etc/openstack_deploy/user_variables.yml`` " "file and set the following three variables:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:205 msgid "Then, run the playbook to apply the certificates:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:211 msgid "" "The playbook deploys your user-provided SSL certificate, key, and CA " "certificate to each RabbitMQ container." msgstr "" #: ../../source/user/security/ssl-certificates.rst:214 msgid "" "The process is identical for the other services. Replace `rabbitmq` in the " "preceding configuration variables with `horizon`, `haproxy`, or `keystone`, " "and then run the playbook for that service to deploy user-provided " "certificates to those services." msgstr "" #: ../../source/user/security/ssl-certificates.rst:220 msgid "Certbot certificates" msgstr "" #: ../../source/user/security/ssl-certificates.rst:222 msgid "" "The HAProxy ansible role supports using certbot to automatically deploy " "trusted SSL certificates for the public endpoint. Each HAProxy server will " "individually request a SSL certificate using certbot." msgstr "" #: ../../source/user/security/ssl-certificates.rst:226 msgid "" "Certbot defaults to using LetsEncrypt as the Certificate Authority, other " "Certificate Authorities can be used by setting the " "``haproxy_ssl_letsencrypt_certbot_server`` variable in the ``/etc/" "openstack_deploy/user_variables.yml`` file:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:235 msgid "" "The http-01 type challenge is used by certbot to deploy certificates so it " "is required that the public endpoint is accessible directly by the " "Certificate Authority." msgstr "" #: ../../source/user/security/ssl-certificates.rst:239 msgid "" "Deployment of certificates using LetsEncrypt has been validated for " "openstack-ansible using Ubuntu Jammy. Other distributions should work but " "are not tested." msgstr "" #: ../../source/user/security/ssl-certificates.rst:243 msgid "" "To deploy certificates with certbot, add the following to ``/etc/" "openstack_deploy/user_variables.yml`` to enable the certbot function in the " "haproxy ansible role, and to create a new backend service called ``certbot`` " "to service http-01 challenge requests." msgstr "" #: ../../source/user/security/ssl-certificates.rst:256 msgid "TLS for Haproxy Internal VIP" msgstr "" #: ../../source/user/security/ssl-certificates.rst:258 msgid "" "As well as load balancing public endpoints, haproxy is also used to load " "balance internal connections." msgstr "" #: ../../source/user/security/ssl-certificates.rst:261 msgid "" "By default, OpenStack-Ansible does not secure connections to the internal " "VIP. To enable this you must set the following variables in the ``/etc/" "openstack_deploy/user_variables.yml`` file:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:272 msgid "Run all playbooks to configure haproxy and openstack services." msgstr "" #: ../../source/user/security/ssl-certificates.rst:274 msgid "" "When enabled haproxy will use the same TLS certificate on all interfaces " "(internal and external). It is not currently possible in OpenStack-Ansible " "to use different self-signed or user-provided TLS certificates on different " "haproxy interfaces." msgstr "" #: ../../source/user/security/ssl-certificates.rst:279 msgid "" "The only way to use a different TLS certificates on the internal and " "external VIP is to use certbot." msgstr "" #: ../../source/user/security/ssl-certificates.rst:282 msgid "" "Enabling TLS on the internal VIP for existing deployments will cause some " "downtime, this is because haproxy only listens on a single well known port " "for each OpenStack service and OpenStack services are configured to use http " "or https. This means once haproxy is updated to only accept HTTPS " "connections, the OpenStack services will stop working until they are updated " "to use HTTPS." msgstr "" #: ../../source/user/security/ssl-certificates.rst:288 msgid "" "To avoid downtime, it is recommended to enable " "``openstack_service_accept_both_protocols`` until all services are " "configured correctly. It allows haproxy frontends to listen on both HTTP and " "HTTPS." msgstr "" #: ../../source/user/security/ssl-certificates.rst:293 msgid "TLS for Haproxy Backends" msgstr "" #: ../../source/user/security/ssl-certificates.rst:295 msgid "" "Communication between haproxy and service backends can be encrypted. " "Currently it is disabled by default. It can be enabled for all services by " "setting the following variable:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:303 msgid "There is also an option to enable it only for individual services:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:310 msgid "" "By default, self-signed certificates will be used to secure traffic but user-" "provided certificates are also supported." msgstr "" #: ../../source/user/security/ssl-certificates.rst:314 msgid "TLS for Live Migrations" msgstr "" #: ../../source/user/security/ssl-certificates.rst:316 msgid "" "Live migration of VM's using SSH is deprecated and the `OpenStack Nova " "Docs`_ recommends using the more secure native TLS method supported by QEMU. " "The default live migration method used by OpenStack-Ansible has been updated " "to use TLS migrations." msgstr "" #: ../../source/user/security/ssl-certificates.rst:323 msgid "" "QEMU-native TLS requires all compute hosts to accept TCP connections on port " "16514 and port range 49152 to 49261." msgstr "" #: ../../source/user/security/ssl-certificates.rst:326 msgid "" "It is not possible to have a mixed estate of some compute nodes using SSH " "and some using TLS for live migrations, as this would prevent live " "migrations between the compute nodes." msgstr "" #: ../../source/user/security/ssl-certificates.rst:330 msgid "" "There are no issues enabling TLS live migration during an OpenStack upgrade, " "as long as you do not need to live migrate instances during the upgrade. If " "you you need to live migrate instances during an upgrade, enable TLS live " "migrations before or after the upgrade." msgstr "" #: ../../source/user/security/ssl-certificates.rst:335 msgid "" "To force the use of SSH instead of TLS for live migrations you must set the " "``nova_libvirtd_listen_tls`` variable to ``0`` in the ``/etc/" "openstack_deploy/user_variables.yml`` file:" msgstr "" #: ../../source/user/security/ssl-certificates.rst:344 msgid "TLS for VNC" msgstr "" #: ../../source/user/security/ssl-certificates.rst:346 msgid "" "When using VNC for console access there are 3 connections to secure, client " "to haproxy, haproxy to noVNC Proxy and noVNC Proxy to Compute nodes. The " "`OpenStack Nova Docs for remote console access`_ cover console security in " "much more detail." msgstr "" #: ../../source/user/security/ssl-certificates.rst:353 msgid "" "In OpenStack-Ansible TLS to haproxy is configured in haproxy, TLS from " "haproxy to noVNC is not currently enabled and TLS from nVNC to Compute nodes " "is enabled by default." msgstr "" #: ../../source/user/security/ssl-certificates.rst:357 msgid "" "Changes will not apply to any existing running guests on the compute node, " "so this configuration should be done before launching any instances. For " "existing deployments it is recommended that you migrate instances off the " "compute node before enabling." msgstr "" #: ../../source/user/security/ssl-certificates.rst:362 msgid "" "To help with the transition from unencrypted VNC to VeNCrypt, initially " "noVNC proxy auth scheme allows for both encrypted and unencrypted sessions " "using the variable `nova_vencrypt_auth_scheme`. This will be restricted to " "VeNCrypt only in future versions of OpenStack-Ansible." msgstr "" #: ../../source/user/security/ssl-certificates.rst:371 msgid "" "To not encrypt data from noVNC proxy to Compute nodes you must set the " "``nova_qemu_vnc_tls`` variable to ``0`` in the ``/etc/openstack_deploy/" "user_variables.yml`` file:" msgstr "" #: ../../source/user/source-overrides/index.rst:3 msgid "Source overriding examples" msgstr "" #: ../../source/user/source-overrides/index.rst:5 msgid "" "There are situations where a deployer want to override sources with its own " "fork." msgstr "" #: ../../source/user/source-overrides/index.rst:8 msgid "" "This chapter gives case-by-case examples on how to override the default " "sources." msgstr "" #: ../../source/user/source-overrides/index.rst:12 msgid "Overriding Ansible version" msgstr "" #: ../../source/user/source-overrides/index.rst:14 msgid "" "Overriding the default Ansible version is not recommended, as each branch of " "OpenStack-Ansible has been built with the a specific Ansible version in " "mind, and many Ansible changes are neither backwards nor forward compatible." msgstr "" #: ../../source/user/source-overrides/index.rst:19 msgid "" "The ``bootstrap-ansible.sh`` script installs Ansible, and uses a variable " "``ANSIBLE_PACKAGE`` to describe which version to install." msgstr "" #: ../../source/user/source-overrides/index.rst:22 msgid "For example to install ansible version 2.5.0:" msgstr "" #: ../../source/user/source-overrides/index.rst:29 msgid "" "Installing directly from git is also supported. For example, from the tip of " "Ansible development branch:" msgstr "" #: ../../source/user/source-overrides/index.rst:38 msgid "Overriding the roles" msgstr "" #: ../../source/user/source-overrides/index.rst:40 msgid "" "Overriding the role file has been explained in the reference guide, on the :" "ref:`extend_osa_roles` section." msgstr "" #: ../../source/user/source-overrides/index.rst:46 msgid "Overriding other upstream projects source code" msgstr "" #: ../../source/user/source-overrides/index.rst:48 msgid "" "All the upstream repositories used are defined in the ``openstack-ansible`` " "integrated repository, in the ``inventory/group_vars//" "source_git.yml`` file." msgstr "" #: ../../source/user/source-overrides/index.rst:52 msgid "" "For example, if you want to override ``glance`` repository with your own, " "you need to define the following:" msgstr "" #: ../../source/user/source-overrides/index.rst:61 msgid "" "Please note, for this glance example, that you do not need to edit the " "``inventory/group_vars/glance_all/source_git.yml`` file." msgstr "" #: ../../source/user/source-overrides/index.rst:64 msgid "" "Instead, the usual overrides mechanism can take place, and you can define " "these 3 variables in a ``user_*.yml`` file. See also the :ref:`user-" "overrides` page." msgstr "" #: ../../source/user/source-overrides/index.rst:70 msgid "" "These variables behave a little differently than standard ansible " "precedence, because they are also consumed by a custom lookup plugin." msgstr "" #: ../../source/user/source-overrides/index.rst:73 msgid "" "The ``py_pkgs lookup`` will ignore all _git_ variables unless the " "``_git_repo`` variable is present." msgstr "" #: ../../source/user/source-overrides/index.rst:76 msgid "" "So even if you only want to override the ``_git_install_branch`` for a " "repository, you should also define the ``_git_repo`` variable in your user " "variables." msgstr "" #: ../../source/user/test/example.rst:3 msgid "Test environment example" msgstr "" #: ../../source/user/test/example.rst:5 msgid "" "Here is an example test environment for a working OpenStack-Ansible (OSA) " "deployment with a small number of servers." msgstr "" #: ../../source/user/test/example.rst:10 msgid "One infrastructure (control plane) host (8 vCPU, 8 GB RAM, 60 GB HDD)" msgstr "" #: ../../source/user/test/example.rst:11 msgid "One compute host (8 vCPU, 8 GB RAM, 60 GB HDD)" msgstr "" #: ../../source/user/test/example.rst:12 msgid "One Network Interface Card (NIC) for each host" msgstr "" #: ../../source/user/test/example.rst:13 msgid "" "A basic compute kit environment, with the Image (glance) and Compute (nova) " "services set to use file-backed storage." msgstr "" #: ../../source/user/test/example.rst:26 msgid "Switch port configuration" msgstr "" #: ../../source/user/test/example.rst:28 msgid "" "The following example provides a good reference for switch configuration and " "cab layout. This example may be more that what is required for basic setups " "however it can be adjusted to just about any configuration. Additionally you " "will need to adjust the VLANS noted within this example to match your " "environment." msgstr "" #: ../../source/user/test/example.rst:64 msgid "172.29.244.12" msgstr "" #: ../../source/user/test/example.rst:66 msgid "172.29.244.13" msgstr "" #: ../../source/user/test/example.rst:66 msgid "storage1" msgstr "" #: ../../source/user/test/example.rst:105 msgid "" "For this environment you do not need the ``/etc/openstack_deploy/env.d`` " "folder as the defaults set by OpenStack-Ansible are suitable." msgstr "" #: ../../source/user/test/example.rst:114 msgid "" "For this environment, if you want to use the same IP address for the " "internal and external endpoints, you will need to ensure that the internal " "and public OpenStack endpoints are served with the same protocol. This is " "done with the following content:" msgstr "" #: ../../source/user/test/example.rst:-1 msgid "Switch port configuration example" msgstr "" #: ../../source/user/test/example.rst:-1 msgid "Test environment host layout" msgstr ""