#, 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/contributor/bugs.rst:0 msgid "A" msgstr "" #: ../../source/contributor/bugs.rst:0 msgid "Q" msgstr "" #: ../../source/contributor/bugs.rst:3 msgid "OpenStack-Ansible Bug Handling" msgstr "" #: ../../source/contributor/bugs.rst:8 msgid "Bug Reporting" msgstr "" #: ../../source/contributor/bugs.rst:10 msgid "Bugs should be filed on the `OpenStack-Ansible Launchpad project`_." msgstr "" #: ../../source/contributor/bugs.rst:12 msgid "" "When submitting a bug, or working on a bug, please ensure the following " "criteria are met:" msgstr "" #: ../../source/contributor/bugs.rst:15 msgid "" "The description clearly states or describes the original problem or root " "cause of the problem." msgstr "" #: ../../source/contributor/bugs.rst:17 msgid "" "The description clearly states the expected outcome of the user action." msgstr "" #: ../../source/contributor/bugs.rst:18 msgid "Include historical information on how the problem was identified." msgstr "" #: ../../source/contributor/bugs.rst:19 msgid "" "Any relevant logs or user configuration are included, either directly or " "through a pastebin." msgstr "" #: ../../source/contributor/bugs.rst:21 msgid "" "If the issue is a bug that needs fixing in a branch other than master, " "please note the associated branch within the launchpad issue." msgstr "" #: ../../source/contributor/bugs.rst:23 msgid "" "The provided information should be totally self-contained. External access " "to web services/sites should not be needed." msgstr "" #: ../../source/contributor/bugs.rst:25 msgid "Steps to reproduce the problem if possible." msgstr "" #: ../../source/contributor/bugs.rst:30 msgid "Bug Tags" msgstr "" #: ../../source/contributor/bugs.rst:31 msgid "" "If the reported needs fixing in a branch in addition to master, add a " "'\\-backport-potential' tag (e.g. ``liberty-backport-potential``)." " There are predefined tags that will auto-complete." msgstr "" #: ../../source/contributor/bugs.rst:36 msgid "Status" msgstr "" #: ../../source/contributor/bugs.rst:37 msgid "" "Please leave the **status** of an issue alone until someone confirms it or a " "member of the bugs team triages it. While waiting for the issue to be " "confirmed or triaged the status should remain as **New**." msgstr "" #: ../../source/contributor/bugs.rst:42 msgid "Importance" msgstr "" #: ../../source/contributor/bugs.rst:43 msgid "" "Should only be touched if it is a Blocker/Gating issue. If it is, please set " "to **High**, and only use **Critical** if you have found a bug that can take " "down whole infrastructures. Once the importance has been changed the status " "should be changed to **Triaged** by someone other than the bug creator." msgstr "" #: ../../source/contributor/bugs.rst:49 msgid "The triaging process is explained here below." msgstr "" #: ../../source/contributor/bugs.rst:54 msgid "Bug triage" msgstr "" #: ../../source/contributor/bugs.rst:57 msgid "What is a bug triage" msgstr "" #: ../../source/contributor/bugs.rst:59 msgid "" "\"Bug triage is a process where tracker issues are screened and prioritised. " "Triage should help ensure we appropriately manage all reported issues - bugs " "as well as improvements and feature requests.\" (Source: `Moodle bug " "triage`_)" msgstr "" #: ../../source/contributor/bugs.rst:66 msgid "" "Reported bugs need confirmation, prioritization, and ensure they do not go " "stale. If you care about OpenStack stability but are not wanting to actively " "develop the roles and playbooks used within the OpenStack-Ansible project, " "consider contributing in the area of bug triage." msgstr "" #: ../../source/contributor/bugs.rst:71 msgid "" "Please reference the `Project Team Guide bugs reference_` for information " "about bug status/importance and the life cycle of a bug." msgstr "" #: ../../source/contributor/bugs.rst:77 msgid "Bug triage meeting duties" msgstr "" #: ../../source/contributor/bugs.rst:79 msgid "" "If the bug description is incomplete, or the report is lacking the " "information necessary to reproduce the issue, ask the reporter to provide " "missing information, and set the bug status to *Incomplete*" msgstr "" #: ../../source/contributor/bugs.rst:84 msgid "" "If the bug report contains enough information and you can reproduce it (or " "it looks valid), then you should set its status to *Confirmed*." msgstr "" #: ../../source/contributor/bugs.rst:87 msgid "" "If the bug has security implications, set the security flag (under \"This " "report is public\" on the top right)" msgstr "" #: ../../source/contributor/bugs.rst:90 msgid "" "If the bug affects a specific area covered by an official tag, you should " "set the tag. For example, if the bug is likely to be quite easy to solve, " "add the `low-hanging-fruit` tag." msgstr "" #: ../../source/contributor/bugs.rst:94 msgid "" "The bug triage meeting is probably a good time for people with bug " "supervisors rights to also prioritize bugs per importance (on top of " "classifying them on status)." msgstr "" #: ../../source/contributor/bugs.rst:99 msgid "Bug skimming duty" msgstr "" #: ../../source/contributor/bugs.rst:101 msgid "" "To help triaging bugs, one person of the bug team can be on \"bug skimming " "duty\"." msgstr "" #: ../../source/contributor/bugs.rst:104 msgid "What is the goal of the bug skimming duty?" msgstr "" #: ../../source/contributor/bugs.rst:105 msgid "" "Bug skimming duty reduces the amount of work other developers have to spend " "to do a proper root cause analysis (and later fix) of bug reports. For this, " "close the obviously invalid bug reports, confirm the obviously valid bug " "reports, ask questions if things are unclear." msgstr "" #: ../../source/contributor/bugs.rst:110 msgid "" "Do I need to prove that a bug report is valid/invalid before I can set it to " "*Confirmed*/*Invalid* ?" msgstr "" #: ../../source/contributor/bugs.rst:112 msgid "" "No. Sometimes it is not even possible because you do not have the resources. " "Looking at the code and tests often enables you to make an educated guess. " "Citing your sources in a comment helps the discussion." msgstr "" #: ../../source/contributor/bugs.rst:117 msgid "" "What is the best status to close a bug report if its issue cannot be " "reproduced?" msgstr "" #: ../../source/contributor/bugs.rst:119 msgid "" "Definitively *Invalid*. The status *Incomplete* is an open state and means " "that more information is necessary." msgstr "" #: ../../source/contributor/bugs.rst:122 msgid "How do I handle open bug reports which are Incomplete for too long?" msgstr "" #: ../../source/contributor/bugs.rst:123 msgid "" "If it is in this state for more than 30 days and no answers to the open " "questions are given, close it with Won't Fix." msgstr "" #: ../../source/contributor/bugs.rst:126 msgid "" "How do I handle dependencies to other bugs or TBD features in other " "projects? For example, I can fix a bug in OpenStack-Ansible but I need that " "a feature in Compute (nova) gets implemented before." msgstr "" #: ../../source/contributor/bugs.rst:129 msgid "" "Leave a comment in the OpenStack-Ansible bug report which explains this " "dependency and leave a link to the blueprint or bug report of the other " "project you depend on." msgstr "" #: ../../source/contributor/bugs.rst:133 msgid "" "Do I have to double-check bug reports which are New and have an assignee?" msgstr "" #: ../../source/contributor/bugs.rst:135 msgid "" "Usually not. This bug report has an inconsistent state though. If a bug " "report has an assignee, it should be In Progress and have an importance set." msgstr "" #: ../../source/contributor/bugs.rst:140 msgid "Bug skimming duty weekly checklist" msgstr "" #: ../../source/contributor/bugs.rst:142 msgid "Prioritize or reprioritize OpenStack-Ansible `confirmed bugs`_." msgstr "" #: ../../source/contributor/bugs.rst:144 msgid "" "Move year old `wishlist bugs`_ to Opinion/Wishlist to remove clutter. You " "can use the following message:" msgstr "" #: ../../source/contributor/bugs.rst:147 msgid "" "This wishlist bug has been open a year without any activity. I am moving " "this to \"Opinion / Wishlist\". This is an easily-obtainable queue of older " "requests. This bug can be reopened (set back to \"New\") if someone decides " "to work on this." msgstr "" #: ../../source/contributor/bugs.rst:152 msgid "" "Move bugs that can not be reproduced to an invalid state if they are " "unmodified for more than a month." msgstr "" #: ../../source/contributor/bugs.rst:155 msgid "" "Send an email to the openstack-discuss list with the `list of bugs to " "triage`_ during the week. A new bug marked as *Critical* or *High* must be " "treated in priority." msgstr "" #: ../../source/contributor/code-rules.rst:5 msgid "Code rules" msgstr "" #: ../../source/contributor/code-rules.rst:10 msgid "General Guidelines for Submitting Code" msgstr "" #: ../../source/contributor/code-rules.rst:12 msgid "" "Write good commit messages. We follow the OpenStack \"`Git Commit Good " "Practice`_\" guide. if you have any questions regarding how to write good " "commit messages please review the upstream OpenStack documentation." msgstr "" #: ../../source/contributor/code-rules.rst:16 msgid "" "Changes to the project should be submitted for review via the Gerrit tool, " "following the `workflow documented here`_." msgstr "" #: ../../source/contributor/code-rules.rst:18 msgid "" "Pull requests submitted through GitHub will be ignored and closed without " "regard." msgstr "" #: ../../source/contributor/code-rules.rst:20 msgid "" "Patches should be focused on solving one problem at a time. If the review is " "overly complex or generally large the initial commit will receive a \"**-" "2**\" and the contributor will be asked to split the patch up across " "multiple reviews. In the case of complex feature additions the design and " "implementation of the feature should be done in such a way that it can be " "submitted in multiple patches using dependencies. Using dependent changes " "should always aim to result in a working build throughout the dependency " "chain. Documentation is available for `advanced gerrit usage`_ too." msgstr "" #: ../../source/contributor/code-rules.rst:28 msgid "" "All patch sets should adhere to the :ref:`Ansible Style Guide` listed here " "as well as adhere to the `Ansible best practices`_ when possible." msgstr "" #: ../../source/contributor/code-rules.rst:30 msgid "" "All changes should be clearly listed in the commit message, with an " "associated bug id/blueprint along with any extra information where " "applicable." msgstr "" #: ../../source/contributor/code-rules.rst:33 msgid "" "Refactoring work should never include additional \"rider\" features. " "Features that may pertain to something that was re-factored should be raised " "as an issue and submitted in prior or subsequent patches." msgstr "" #: ../../source/contributor/code-rules.rst:36 msgid "" "New features, breaking changes and other patches of note must include a " "release note generated using `the reno tool`_. Please see the :ref:" "`Documentation and Release Note Guidelines` for more " "information." msgstr "" #: ../../source/contributor/code-rules.rst:40 msgid "" "All patches including code, documentation and release notes should be built " "and tested locally with the appropriate test suite before submitting for " "review. See :ref:`Development and Testing` for more " "information." msgstr "" #: ../../source/contributor/code-rules.rst:54 msgid "Documentation and Release Note Guidelines" msgstr "" #: ../../source/contributor/code-rules.rst:56 msgid "" "Documentation is a critical part of ensuring that the deployers of OpenStack-" "Ansible are appropriately informed about:" msgstr "" #: ../../source/contributor/code-rules.rst:59 msgid "How to use the project's tooling effectively to deploy OpenStack." msgstr "" #: ../../source/contributor/code-rules.rst:60 msgid "" "How to implement the right configuration to meet the needs of their specific " "use-case." msgstr "" #: ../../source/contributor/code-rules.rst:62 msgid "" "Changes in the project over time which may affect an existing deployment." msgstr "" #: ../../source/contributor/code-rules.rst:64 msgid "" "To meet these needs developers must submit :ref:`code " "comments`, documentation (see also the :ref:`documentation " "locations section`) and :ref:`release notes` with any " "code submissions." msgstr "" #: ../../source/contributor/code-rules.rst:69 msgid "" "All forms of documentation should comply with the guidelines provided in the " "`OpenStack Documentation Contributor Guide`_, with particular reference to " "the following sections:" msgstr "" #: ../../source/contributor/code-rules.rst:73 msgid "Writing style" msgstr "" #: ../../source/contributor/code-rules.rst:74 msgid "RST formatting conventions" msgstr "" #: ../../source/contributor/code-rules.rst:81 msgid "Code Comments" msgstr "" #: ../../source/contributor/code-rules.rst:83 msgid "" "Code comments for variables should be used to explain the purpose of the " "variable. This is particularly important for the role defaults file as the " "file is included verbatim in the role's documentation. Where there is an " "optional variable, the variable and an explanation of what it is used for " "should be added to the defaults file." msgstr "" #: ../../source/contributor/code-rules.rst:89 msgid "" "Code comments for bash/python scripts should give guidance to the purpose of " "the code. This is important to provide context for reviewers before the " "patch has merged, and for later modifications to remind the contributors " "what the purpose was and why it was done that way." msgstr "" #: ../../source/contributor/code-rules.rst:97 msgid "Documentation locations" msgstr "" #: ../../source/contributor/code-rules.rst:99 msgid "" "OpenStack-Ansible has multiple forms of documentation with different intent." msgstr "" #: ../../source/contributor/code-rules.rst:101 msgid "" "The :deploy_guide:`Deployment Guide ` intends to help deployers " "deploy OpenStack-Ansible for the first time." msgstr "" #: ../../source/contributor/code-rules.rst:104 msgid "" "The :dev_docs:`User Guide ` intends to provide user stories " "on how to do specific things with OpenStack-Ansible." msgstr "" #: ../../source/contributor/code-rules.rst:107 msgid "" "The :dev_docs:`Operations Guide ` provide help on how to " "manage and operate OpenStack-Ansible." msgstr "" #: ../../source/contributor/code-rules.rst:110 msgid "" "The in-depth technical information is located in the :dev_docs:`OpenStack-" "Ansible Reference `." msgstr "" #: ../../source/contributor/code-rules.rst:113 msgid "" "The role documentation (for example, the `keystone role documentation`_) " "intends to explain all the options available for the role and how to " "implement more advanced requirements. To reduce duplication, the role " "documentation directly includes the role's default variables file which " "includes the comments explaining the purpose of the variables. The long hand " "documentation for the roles should focus less on explaining variables and " "more on explaining how to implement advanced use cases." msgstr "" #: ../../source/contributor/code-rules.rst:121 msgid "" "The role documentation must include a description of the mandatory " "infrastructure (For example: a database and a message queue are required), " "variables (For example: the database name and credentials) and group names " "(For example: The role expects a group named ``foo_all`` to be present and " "it expects the host to be a member of it) for the role's execution to " "succeed." msgstr "" #: ../../source/contributor/code-rules.rst:128 msgid "" "Where possible the documentation in OpenStack-Ansible should steer clear of " "trying to explain OpenStack concepts. Those explanations belong in the " "OpenStack Manuals or service documentation and OpenStack-Ansible " "documentation should link to those documents when available, rather than " "duplicate their content." msgstr "" #: ../../source/contributor/code-rules.rst:139 msgid "Release Notes" msgstr "" #: ../../source/contributor/code-rules.rst:141 msgid "" "Release notes are generated using `the reno tool`_. Release notes must be " "written with the following guidelines in mind:" msgstr "" #: ../../source/contributor/code-rules.rst:144 msgid "" "Each list item must make sense to read without the context of the patch or " "the repository the patch is being submitted into. The reason for this is " "that all release notes are consolidated and presented in a long list without " "reference to the source patch or the context of the repository." msgstr "" #: ../../source/contributor/code-rules.rst:148 msgid "" "Each note should be brief and to the point. Try to avoid multi-paragraph " "notes. For features the note should typically refer to documentation for " "more details. For bug fixes the note can refer to a registered bug for more " "details." msgstr "" #: ../../source/contributor/code-rules.rst:153 msgid "" "In most cases only the following sections should be used for new release " "notes submitted with patches:" msgstr "" #: ../../source/contributor/code-rules.rst:156 msgid "" "``features``: This should inform the deployer briefly about a new feature " "and should describe how to use it either by referencing the variables to set " "or by referring to documentation." msgstr "" #: ../../source/contributor/code-rules.rst:159 msgid "" "``issues``: This should inform the deployer about known issues. This may be " "used when fixing an issue and wanting to inform deployers about a workaround " "that can be used for versions prior to that which contains the patch that " "fixes the issue. Issue notes should specifically make mention of what " "versions of OpenStack-Ansible are affected by the issue." msgstr "" #: ../../source/contributor/code-rules.rst:164 msgid "" "``upgrade``: This should inform the deployer about changes which may affect " "them when upgrading from a previous major or minor version. Typically, these " "notes would describe changes to default variable values or variables that " "have been removed." msgstr "" #: ../../source/contributor/code-rules.rst:168 msgid "" "``deprecations``: If a variable has been deprecated (ideally using the " "deprecation filter), then it should be communicated through notes in this " "section. Note that if a variable has been removed entirely then it has not " "been deprecated and the removal should be noted in the ``upgrade`` section." msgstr "" #: ../../source/contributor/code-rules.rst:176 msgid "Submitting a specification" msgstr "" #: ../../source/contributor/code-rules.rst:178 msgid "" "By proposing a draft spec you can help the OpenStack-Ansible community keep " "track of what roles or large changes are being developed, and perhaps " "connect you with others who may be interested and able to help you in the " "process." msgstr "" #: ../../source/contributor/code-rules.rst:183 msgid "" "Our specifications repository follows the usual OpenStack and OpenStack-" "Ansible guidelines for submitting code." msgstr "" #: ../../source/contributor/code-rules.rst:186 msgid "" "However, to help you in the writing of the specification, we have a " "`specification template`_ that can be copied into the latest release name " "folder. Rename and edit it for your needs." msgstr "" #: ../../source/contributor/code-rules.rst:195 msgid "Ansible Style Guide" msgstr "" #: ../../source/contributor/code-rules.rst:198 msgid "YAML formatting" msgstr "" #: ../../source/contributor/code-rules.rst:200 msgid "" "When creating tasks and other roles for use in Ansible please create them " "using the YAML dictionary format." msgstr "" #: ../../source/contributor/code-rules.rst:203 msgid "Example YAML dictionary format:" msgstr "" #: ../../source/contributor/code-rules.rst:216 msgid "Example what **NOT** to do:" msgstr "" #: ../../source/contributor/code-rules.rst:233 msgid "" "Usage of the \">\" and \"|\" operators should be limited to Ansible " "conditionals and command modules such as the Ansible ``shell`` or " "``command``." msgstr "" #: ../../source/contributor/code-rules.rst:237 msgid "Tags and tags conventions" msgstr "" #: ../../source/contributor/code-rules.rst:239 msgid "" "Tags are assigned based on the relevance of each individual item. Higher " "level includes (for example in the ``tasks/main.yml``) need high level tags. " "For example, ``*-config`` or ``*-install``. Included tasks can have more " "detailed tags." msgstr "" #: ../../source/contributor/code-rules.rst:244 msgid "The following convention is used:" msgstr "" #: ../../source/contributor/code-rules.rst:246 msgid "" "A tag including the word ``install`` handles software installation tasks. " "Running a playbook with ``--tags -install`` only deploys the necessary " "software on the target, and will not configure it to your needs or run any " "service." msgstr "" #: ../../source/contributor/code-rules.rst:251 msgid "" "A tag including the word ``config`` prepares the configuration of the " "software (adapted to your needs), and all the components necessary to run " "the service(s) configured in the role. Running a playbook with ``--tags " "-config`` is only possible if the target already ran the tags ``-" "install``." msgstr "" #: ../../source/contributor/code-rules.rst:257 msgid "A tag including the word ``upgrade`` handles all the upgrade tasks." msgstr "" #: ../../source/contributor/code-rules.rst:260 msgid "Variable files conventions" msgstr "" #: ../../source/contributor/code-rules.rst:262 msgid "The variables files in a role are split in 3 locations:" msgstr "" #: ../../source/contributor/code-rules.rst:264 msgid "The `defaults/main.yml` file" msgstr "" #: ../../source/contributor/code-rules.rst:265 msgid "The `vars/main.yml` file" msgstr "" #: ../../source/contributor/code-rules.rst:266 msgid "The `vars/.yml` file" msgstr "" #: ../../source/contributor/code-rules.rst:268 msgid "" "The variables with lower priority should be in the `defaults/main.yml`. This " "allows their overriding with group variables or host variables. A good " "example for this are default database connection details, default queues " "connection details, or debug mode." msgstr "" #: ../../source/contributor/code-rules.rst:273 msgid "" "In other words, `defaults/main.yml` contains variables that are meant to be " "overridable by a deployer or a continuous integration system. These " "variables should be limited as much as possible, to avoid increasing the " "test matrix." msgstr "" #: ../../source/contributor/code-rules.rst:278 msgid "" "The `vars/main.yml` is always included. It contains generic variables that " "aren't meant to be changed by a deployer. This includes for example static " "information that aren't distribution specific (like aggregation of role " "internal variables for example)." msgstr "" #: ../../source/contributor/code-rules.rst:283 msgid "" "The `vars/.yml` is the place where distribution specific " "content will be stored. For example, this file will hold the package names, " "repositories urls and keys, file paths, service names/init scripts." msgstr "" #: ../../source/contributor/code-rules.rst:289 msgid "Secrets" msgstr "" #: ../../source/contributor/code-rules.rst:291 msgid "" "Any secrets (For example: passwords) should not be provided with default " "values in the tasks, role vars, or role defaults. The tasks should be " "implemented in such a way that any secrets required, but not provided, " "should result in the task execution failure. It is important for a secure-by-" "default implementation to ensure that an environment is not vulnerable due " "to the production use of default secrets. Deployers must be forced to " "properly provide their own secret variable values." msgstr "" #: ../../source/contributor/code-rules.rst:300 msgid "Task files conventions" msgstr "" #: ../../source/contributor/code-rules.rst:302 msgid "" "Most OpenStack services will follow a common series of stages to install, " "configure, or update a service deployment. This is apparent when you review " "`tasks/main.yml` for existing roles." msgstr "" #: ../../source/contributor/code-rules.rst:306 msgid "" "If developing a new role, please follow the conventions set by existing " "roles." msgstr "" #: ../../source/contributor/code-rules.rst:310 msgid "Tests conventions" msgstr "" #: ../../source/contributor/code-rules.rst:312 msgid "" "The conventions for writing tests are described in the :ref:`tests` page." msgstr "" #: ../../source/contributor/code-rules.rst:316 msgid "Other OpenStack-Ansible conventions" msgstr "" #: ../../source/contributor/code-rules.rst:318 msgid "" "To facilitate the development and tests implemented across all OpenStack-" "Ansible roles, a base set of folders and files need to be implemented. A " "base set of configuration and test facilitation scripts must include at " "least the following:" msgstr "" #: ../../source/contributor/code-rules.rst:323 msgid "" "``tox.ini``: The lint testing, documentation build, release note build and " "functional build execution process for the role's gate tests are all defined " "in this file." msgstr "" #: ../../source/contributor/code-rules.rst:327 msgid "" "``test-requirements.txt``: The Python requirements that must be installed " "when executing the tests." msgstr "" #: ../../source/contributor/code-rules.rst:330 msgid "" "``bindep.txt``: The binary requirements that must be installed on the host " "the tests are executed on for the Python requirements and the tox execution " "to work. This must be copied from the ``openstack-ansible-tests`` repository " "and will be automatically be overridden by our proposal bot should any " "change happen." msgstr "" #: ../../source/contributor/code-rules.rst:336 msgid "" "``setup.cfg`` and ``setup.py``: Information about the repository used when " "building artifacts." msgstr "" #: ../../source/contributor/code-rules.rst:338 msgid "" "``run_tests.sh``: A script for developers to execute all standard tests on a " "suitable host. This must be copied from the ``openstack-ansible-tests`` " "repository and will be automatically be overridden by our proposal bot " "should any change happen." msgstr "" #: ../../source/contributor/code-rules.rst:343 msgid "" "``Vagrantfile``: A configuration file to allow a developer to easily create " "a test virtual machine using `Vagrant`_. This must automatically execute " "``run_tests.sh``. This must be copied from the ``openstack-ansible-tests`` " "repository and will be automatically be overridden by our proposal bot " "should any change happen." msgstr "" #: ../../source/contributor/code-rules.rst:349 msgid "" "``README.rst``, ``LICENSE``, ``CONTRIBUTING.rst``: A set of standard files " "whose content is self-explanatory." msgstr "" #: ../../source/contributor/code-rules.rst:351 msgid "" "``.gitignore``: A standard git configuration file for the repository which " "should be pretty uniform across all the repositories. This must be copied " "from the ``openstack-ansible-tests`` repository and will be automatically be " "overridden by our proposal bot should any change happen." msgstr "" #: ../../source/contributor/code-rules.rst:356 msgid "" "``.gitreview``: A standard file configured for the project to inform the " "``git-review`` plugin where to find the upstream gerrit remote for the " "repository." msgstr "" #: ../../source/contributor/code-rules.rst:359 msgid "" "``docs/`` and ``releasenotes/`` folders need to be exist and be properly " "configured." msgstr "" #: ../../source/contributor/code-rules.rst:362 msgid "" "Please have a look at a role like os_cinder, os_keystone, or os_neutron for " "latest files." msgstr "" #: ../../source/contributor/code-rules.rst:368 msgid "Container technology independence" msgstr "" #: ../../source/contributor/code-rules.rst:370 msgid "" "The role implementation should be done in such a way that it is agnostic " "with regards to whether it is implemented in a container, or on a physical " "host. The test infrastructure may make use of containers for the separation " "of services, but if a role is used by a playbook that targets a host, it " "must work regardless of whether that host is a container, a virtual server, " "or a physical server. The use of containers for role tests is not required " "but it may be useful in order to simulate a multi-node build out as part of " "the testing infrastructure." msgstr "" #: ../../source/contributor/code-rules.rst:380 msgid "Minimum supported distributions" msgstr "" #: ../../source/contributor/code-rules.rst:382 msgid "See our :ref:`supported-distros` page." msgstr "" #: ../../source/contributor/contribute.rst:5 msgid "Contributor Guidelines" msgstr "" #: ../../source/contributor/contribute.rst:8 msgid "Before submitting code" msgstr "" #: ../../source/contributor/contribute.rst:10 msgid "" "Before jumping ahead and working on code, a series of steps should be taken:" msgstr "" #: ../../source/contributor/contribute.rst:13 msgid "" "Is there a bug for it? Can your track if someone else has seen the same bug?" msgstr "" #: ../../source/contributor/contribute.rst:15 msgid "" "Are you sure nobody is working on this problem at the moment? Could there be " "a review pending fixing the same issue?" msgstr "" #: ../../source/contributor/contribute.rst:17 msgid "" "Have you checked if your issue/feature request hasn't been solved in another " "branch?" msgstr "" #: ../../source/contributor/contribute.rst:20 msgid "If you're willing to submit code, please remember the following rules:" msgstr "" #: ../../source/contributor/contribute.rst:22 msgid "All code should match our :ref:`codeguidelines`." msgstr "" #: ../../source/contributor/contribute.rst:24 msgid "All code requires to go through our :ref:`reviews`." msgstr "" #: ../../source/contributor/contribute.rst:25 msgid "" "Documentation should be provided with the code directly. See also :ref:" "`documentation`." msgstr "" #: ../../source/contributor/contribute.rst:27 msgid "" "Fixing bugs and increasing test coverage have priority to new features. See " "also the section :ref:`bugfixing`." msgstr "" #: ../../source/contributor/contribute.rst:29 msgid "" "New features are following a process, explained in the section :ref:" "`newfeatures`. New features are less likely to be :ref:" "`backported` to previous branches." msgstr "" #: ../../source/contributor/contribute.rst:37 msgid "Review process" msgstr "" #: ../../source/contributor/contribute.rst:39 msgid "Any new code will be reviewed before merging into our repositories." msgstr "" #: ../../source/contributor/contribute.rst:41 #: ../../source/contributor/contributing.rst:98 msgid "" "We follow openstack guidelines for the `code reviewing `_ process." msgstr "" #: ../../source/contributor/contribute.rst:43 #: ../../source/contributor/contributing.rst:100 msgid "" "Please be aware that any patch can be refused by the community if they don't " "match the :ref:`codeguidelines`." msgstr "" #: ../../source/contributor/contribute.rst:49 msgid "Working on bug fixes" msgstr "" #: ../../source/contributor/contribute.rst:51 msgid "Any bug fix should have, in its commit message:" msgstr "" #: ../../source/contributor/contribute.rst:53 msgid "Closes-Bug: #bugnumber" msgstr "" #: ../../source/contributor/contribute.rst:55 msgid "or" msgstr "" #: ../../source/contributor/contribute.rst:57 msgid "Related-Bug: #bugnumber" msgstr "" #: ../../source/contributor/contribute.rst:59 msgid "where #bugnumber refers to a Launchpad issue." msgstr "" #: ../../source/contributor/contribute.rst:61 msgid "" "See also the `working on bugs`_ section of the openstack documentation." msgstr "" #: ../../source/contributor/contribute.rst:68 msgid "Working on new features" msgstr "" #: ../../source/contributor/contribute.rst:70 #: ../../source/contributor/contributing.rst:59 msgid "" "If you would like to contribute towards a role to introduce an OpenStack or " "infrastructure service, or to improve an existing role, the OpenStack-" "Ansible project would welcome that contribution and your assistance in " "maintaining it." msgstr "" #: ../../source/contributor/contribute.rst:75 msgid "Here are a few rules to get started:" msgstr "" #: ../../source/contributor/contribute.rst:77 msgid "" "All large feature additions/deletions should be accompanied by a blueprint/" "spec. e.g. adding additional active agents to neutron, developing a new " "service role, etc... See also :ref:`specs`." msgstr "" #: ../../source/contributor/contribute.rst:81 msgid "" "Before creating blueprint/spec an associated 'Wishlist Bug' can be raised on " "launchpad. This issue will be triaged and a determination will be made on " "how large the change is and whether or not the change warrants a blueprint/" "spec. Both features and bug fixes may require the creation of a blueprint/" "spec. This requirement will be voted on by core reviewers and will be based " "on the size and impact of the change." msgstr "" #: ../../source/contributor/contribute.rst:87 msgid "" "All blueprints/specs should be voted on and approved by core reviewers " "before any associated code will be merged. For more information on " "blueprints/specs please review the OpenStack documentation regarding " "`Working on Specifications and Blueprints`_ and our own :ref:`specs`." msgstr "" #: ../../source/contributor/contribute.rst:92 msgid "" "Once the blueprint work is completed the author(s) can request a backport of " "the blueprint work into a stable branch. Each backport will be evaluated on " "a case by case basis with cautious consideration based on how the backport " "affects any existing deployments. See the :ref:`backport` section for more " "information." msgstr "" #: ../../source/contributor/contribute.rst:97 msgid "" "Any new OpenStack services implemented which have `Tempest`_ tests available " "must be implemented along with suitable functional tests enabled as part of " "the feature development in order to ensure that any changes to the code base " "do not break the service functionality." msgstr "" #: ../../source/contributor/contribute.rst:101 msgid "" "Feature additions must include documentation which provides reference to " "OpenStack documentation about what the feature is and how it works. The " "documentation should then describe how it is implemented in OpenStack-" "Ansible and what configuration options there are. See also the :ref:" "`documentation` section." msgstr "" #: ../../source/contributor/contribute.rst:112 msgid "Example process to develop a new role" msgstr "" #: ../../source/contributor/contribute.rst:114 msgid "Here are the steps to write the role:" msgstr "" #: ../../source/contributor/contribute.rst:116 msgid "" "You can review roles which may be currently in development by checking our " "`specs repository`_ and `unmerged specs`_ on review.openstack.org. If you do " "not find a spec for the role, propose a blueprint/spec. See also :ref:" "`specs`." msgstr "" #: ../../source/contributor/contribute.rst:120 msgid "" "Create a source repository (e.g. on Github) to start your work on the Role." msgstr "" #: ../../source/contributor/contribute.rst:121 msgid "" "Generate the reference directory structure for an Ansible role which is the " "necessary subset of the documented `Best Practice`_. You might use Ansible " "Galaxy tools to do this for you (e.g. ``ansible-galaxy init``). You may " "additionally want to include directories such as ``docs`` and ``examples`` " "and ``tests`` for your role." msgstr "" #: ../../source/contributor/contribute.rst:126 msgid "" "Generate a meta/main.yml right away. This file is important to Ansible to " "ensure your dependent roles are installed and available and provides others " "with the information they will need to understand the purpose of your role." msgstr "" #: ../../source/contributor/contribute.rst:130 msgid "" "Develop task files for each of the install stages in turn, creating any " "handlers and templates as needed. Ensure that you notify handlers after any " "task which impacts the way the service would run (such as configuration file " "modifications). Also take care that file ownership and permissions are " "appropriate." msgstr "" #: ../../source/contributor/contribute.rst:136 msgid "" "Fill in variable defaults, libraries, and prerequisites as you discover a " "need for them. You can also develop documentation for your role at the same " "time." msgstr "" #: ../../source/contributor/contribute.rst:140 msgid "Add tests to the role. See also our :ref:`tests` page." msgstr "" #: ../../source/contributor/contribute.rst:141 msgid "" "Ensuring the role matches OpenStack-Ansible's latest standards. See also our " ":ref:`code_rules` page." msgstr "" #: ../../source/contributor/contribute.rst:143 msgid "Ensure the role converges:" msgstr "" #: ../../source/contributor/contribute.rst:145 msgid "" "Implement **developer_mode** to build from a git source into a Python " "virtual environment." msgstr "" #: ../../source/contributor/contribute.rst:147 msgid "Deploy the applicable configuration files in the right places." msgstr "" #: ../../source/contributor/contribute.rst:148 msgid "Ensure that the service starts." msgstr "" #: ../../source/contributor/contribute.rst:150 msgid "" "The convergence may involve consuming other OpenStack-Ansible roles (For " "example: **galera_server, galera_client, rabbitmq_server**) in order to " "ensure that the appropriate infrastructure is in place. Re-using existing " "roles in OpenStack-Ansible or Ansible Galaxy is strongly encouraged." msgstr "" #: ../../source/contributor/contribute.rst:155 msgid "" "Once the initial convergence is working and the services are running, the " "role development should focus on implementing some level of functional " "testing. See also :ref:`tempest-testing`." msgstr "" #: ../../source/contributor/contribute.rst:158 msgid "Test the role on a new machine, using our provided scripts." msgstr "" #: ../../source/contributor/contribute.rst:159 msgid "Submit your role for review." msgstr "" #: ../../source/contributor/contribute.rst:160 msgid "" "If required, ask the OpenStack-Ansible PTL to import the github role into " "the openstack-ansible namespace (This can only be done early in the " "development cycle, and may be postponed to next cycle)." msgstr "" #: ../../source/contributor/contribute.rst:164 msgid "" "If necessary, work on the integration within the openstack-ansible " "integrated repository, and deploy the role on an AIO. See also :ref:" "`integrate-new-role-with-aio`." msgstr "" #: ../../source/contributor/contribute.rst:173 msgid "Example process for adding a feature to an existing role" msgstr "" #: ../../source/contributor/contribute.rst:175 msgid "" "Search for in the `OpenStack-Ansible Launchpad project`_ for the feature " "request." msgstr "" #: ../../source/contributor/contribute.rst:177 msgid "" "If no \"Wishlist\" item exist in Launchpad for your feature, create a bug " "for it. Don't hesitate to ask if a spec is required in the bug." msgstr "" #: ../../source/contributor/contribute.rst:180 msgid "" "The :ref:`bug_triage` will classify if this new feature requires a spec or " "not." msgstr "" #: ../../source/contributor/contribute.rst:182 msgid "Work on the role files, following our :ref:`code_rules`." msgstr "" #: ../../source/contributor/contribute.rst:183 msgid "" "Add an extra role test scenario, to ensure your code path is tested and " "working." msgstr "" #: ../../source/contributor/contribute.rst:185 msgid "" "Test your new scenario with a new machine. See also the :ref:" "`devel_and_testing` page." msgstr "" #: ../../source/contributor/contribute.rst:187 msgid "" "Submit your code for review, with its necessary documentation and release " "notes." msgstr "" #: ../../source/contributor/contribute.rst:194 msgid "Example process to incubate a new \"ops\" project" msgstr "" #: ../../source/contributor/contribute.rst:196 msgid "" "A new project in \"openstack-ansible-ops\" can be started at any time, with " "no constraint like writing a specification, or creating a bug." msgstr "" #: ../../source/contributor/contribute.rst:199 msgid "" "Instead, the new code has to be isolated on a separate folder of the " "`openstack-ansible-ops repo`_." msgstr "" #: ../../source/contributor/contribute.rst:208 msgid "Backporting" msgstr "" #: ../../source/contributor/contribute.rst:210 msgid "" "Backporting is defined as the act of reproducing a change from another " "branch. Unclean/squashed/modified cherry-picks and complete " "reimplementations are OK." msgstr "" #: ../../source/contributor/contribute.rst:213 msgid "" "Backporting is often done by using the same code (via cherry picking), but " "this is not always the case. This method is preferred when the cherry-pick " "provides a complete solution for the targeted problem." msgstr "" #: ../../source/contributor/contribute.rst:216 msgid "" "When cherry-picking a commit from one branch to another the commit message " "should be amended with any files that may have been in conflict while " "performing the cherry-pick operation. Additionally, cherry-pick commit " "messages should contain the original commit *SHA* near the bottom of the new " "commit message. This can be done with ``cherry-pick -x``. Here's more " "information on `Submitting a change to a branch for review`_." msgstr "" #: ../../source/contributor/contribute.rst:222 msgid "" "Every backport commit must still only solve one problem, as per the " "guidelines in :ref:`codeguidelines`." msgstr "" #: ../../source/contributor/contribute.rst:224 msgid "" "If a backport is a squashed set of cherry-picked commits, the original SHAs " "should be referenced in the commit message and the reason for squashing the " "commits should be clearly explained." msgstr "" #: ../../source/contributor/contribute.rst:227 msgid "" "When a cherry-pick is modified in any way, the changes made and the reasons " "for them must be explicitly expressed in the commit message." msgstr "" #: ../../source/contributor/contribute.rst:229 msgid "Refactoring work must not be backported to a \"released\" branch." msgstr "" #: ../../source/contributor/contribute.rst:230 msgid "" "Backport reviews should be done with due consideration to the effect of the " "patch on any existing environment deployed by OpenStack-Ansible. The general " "`OpenStack Guidelines for stable branches`_ can be used as a reference." msgstr "" #: ../../source/contributor/contributing.rst:3 msgid "So You Want to Contribute..." msgstr "" #: ../../source/contributor/contributing.rst:5 msgid "" "For general information on contributing to OpenStack, please check out the " "`contributor guide `_ to get " "started. It covers all the basics that are common to all OpenStack projects: " "the accounts you need, the basics of interacting with our Gerrit review " "system, how we communicate as a community, etc." msgstr "" #: ../../source/contributor/contributing.rst:11 msgid "" "Below will cover the more project specific information you need to get " "started with OpenStack-Ansible." msgstr "" #: ../../source/contributor/contributing.rst:15 msgid "Communication" msgstr "" #: ../../source/contributor/contributing.rst:18 #: ../../source/contributor/project-onboarding.rst:96 msgid "IRC channel" msgstr "" #: ../../source/contributor/contributing.rst:22 #: ../../source/contributor/project-onboarding.rst:101 msgid "" "The OpenStack Community moved the IRC network from Freenode to OFTC on May " "31, 2021. All the current IRC channels used in The OpenStack community are " "registered in OFTC network too." msgstr "" #: ../../source/contributor/contributing.rst:26 msgid "" "The OpenStack-Ansible community communicates in the #openstack-ansible IRC " "channel hosted on OFTC. This channel is logged, and its logs are published " "on http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/." msgstr "" #: ../../source/contributor/contributing.rst:30 msgid "" "Weekly meetings are held in our IRC channel. The schedule and logs can be " "found on http://eavesdrop.openstack.org/" "#OpenStack_Ansible_Deployment_Meeting. The agenda for the next meeting can " "be found on our `Meetings wiki page `_." msgstr "" #: ../../source/contributor/contributing.rst:37 #: ../../source/contributor/project-onboarding.rst:117 msgid "Mailing lists" msgstr "" #: ../../source/contributor/contributing.rst:39 msgid "" "Members of the OpenStack-Ansible community should monitor the **OpenStack-" "discuss** `mailing lists`_." msgstr "" #: ../../source/contributor/contributing.rst:44 #: ../../source/contributor/project-onboarding.rst:124 msgid "" "All our communications should be prefixed with **[openstack-ansible]**." msgstr "" #: ../../source/contributor/contributing.rst:47 msgid "Contacting the Core Team" msgstr "" #: ../../source/contributor/contributing.rst:49 msgid "" "All of our core team is available through IRC and present in #openstack-" "ansible channel on OFTC. The list of the current members of the OpenStack-" "Ansible Team might be found on `gerrit`_." msgstr "" #: ../../source/contributor/contributing.rst:57 msgid "New Feature Planning" msgstr "" #: ../../source/contributor/contributing.rst:64 msgid "" "Please look through :dev_docs:`Contributor Guidelines ` page for more information about the process." msgstr "" #: ../../source/contributor/contributing.rst:69 msgid "Task Tracking" msgstr "" #: ../../source/contributor/contributing.rst:71 msgid "We track our tasks in Launchpad" msgstr "" #: ../../source/contributor/contributing.rst:73 msgid "https://bugs.launchpad.net/openstack-ansible" msgstr "" #: ../../source/contributor/contributing.rst:76 msgid "" "If you're looking for some smaller, easier work item to pick up and get " "started on, search for the 'low-hanging-fruit' tag." msgstr "" #: ../../source/contributor/contributing.rst:81 msgid "Reporting a Bug" msgstr "" #: ../../source/contributor/contributing.rst:83 msgid "" "You found an issue and want to make sure we are aware of it? You can do so " "on `Launchpad `_." msgstr "" #: ../../source/contributor/contributing.rst:88 msgid "" "Also you may find more detailed information about how to work with bugs on " "the page :dev_docs:`Bug Handling `" msgstr "" #: ../../source/contributor/contributing.rst:93 msgid "Getting Your Patch Merged" msgstr "" #: ../../source/contributor/contributing.rst:95 msgid "" "Any new code will be reviewed before merging into our repositories and " "requires at least 2 approvals from our Core team." msgstr "" #: ../../source/contributor/contributing.rst:105 msgid "Project Team Lead Duties" msgstr "" #: ../../source/contributor/contributing.rst:107 msgid "" "All common PTL duties are enumerated in the `PTL guide `_." msgstr "" #: ../../source/contributor/contributing.rst:110 msgid "" "All Core reviewer duties are described on the page :dev_docs:`Core Reviewers " "`." msgstr "" #: ../../source/contributor/core-reviewers.rst:3 msgid "Core Reviewers" msgstr "" #: ../../source/contributor/core-reviewers.rst:6 msgid "General Responsibilities" msgstr "" #: ../../source/contributor/core-reviewers.rst:8 msgid "" "The `OpenStack-Ansible Core Reviewer Team`_ is responsible for many aspects " "of the OpenStack-Ansible project. These include, but are not limited to:" msgstr "" #: ../../source/contributor/core-reviewers.rst:11 msgid "" "Mentor community contributors in solution design, testing, and the review " "process" msgstr "" #: ../../source/contributor/core-reviewers.rst:13 msgid "" "Actively reviewing patch submissions, considering whether the patch: - is " "functional - fits the use-cases and vision of the project - is complete in " "terms of testing, documentation, and release notes - takes into " "consideration upgrade concerns from previous versions" msgstr "" #: ../../source/contributor/core-reviewers.rst:18 msgid "Assist in bug triage and delivery of bug fixes" msgstr "" #: ../../source/contributor/core-reviewers.rst:19 msgid "Curating the gate and triaging failures" msgstr "" #: ../../source/contributor/core-reviewers.rst:20 msgid "Maintaining accurate, complete, and relevant documentation" msgstr "" #: ../../source/contributor/core-reviewers.rst:21 msgid "" "Ensuring the level of testing is adequate and remains relevant as features " "are added" msgstr "" #: ../../source/contributor/core-reviewers.rst:23 msgid "Answering questions and participating in mailing list discussions" msgstr "" #: ../../source/contributor/core-reviewers.rst:24 msgid "Interfacing with other OpenStack teams" msgstr "" #: ../../source/contributor/core-reviewers.rst:26 msgid "In essence, core reviewers share the following common ideals:" msgstr "" #: ../../source/contributor/core-reviewers.rst:28 msgid "They share responsibility in the project's success in its `mission`_." msgstr "" #: ../../source/contributor/core-reviewers.rst:29 msgid "" "They value a healthy, vibrant, and active developer and user community." msgstr "" #: ../../source/contributor/core-reviewers.rst:30 msgid "" "They have made a long-term, recurring time investment to improve the project." "" msgstr "" #: ../../source/contributor/core-reviewers.rst:32 msgid "" "They spend their time doing what needs to be done to ensure the project's " "success, not necessarily what is the most interesting or fun." msgstr "" #: ../../source/contributor/core-reviewers.rst:34 msgid "A core reviewer's responsibility doesn't end with merging code." msgstr "" #: ../../source/contributor/core-reviewers.rst:40 msgid "Core Reviewer Expectations" msgstr "" #: ../../source/contributor/core-reviewers.rst:42 msgid "Members of the core reviewer team are expected to:" msgstr "" #: ../../source/contributor/core-reviewers.rst:44 msgid "Attend and participate in the weekly IRC meetings" msgstr "" #: ../../source/contributor/core-reviewers.rst:45 msgid "Monitor and participate in-channel at #openstack-ansible" msgstr "" #: ../../source/contributor/core-reviewers.rst:46 msgid "" "Monitor and participate in OpenStack-Ansible discussions on the mailing list" msgstr "" #: ../../source/contributor/core-reviewers.rst:47 msgid "" "Participate in team sessions at the OpenStack Projects Team Gatherings (PTG)" msgstr "" #: ../../source/contributor/core-reviewers.rst:48 msgid "Participate in Forum sessions at the OpenStack Summits" msgstr "" #: ../../source/contributor/core-reviewers.rst:49 msgid "Review patch submissions actively and consistently" msgstr "" #: ../../source/contributor/core-reviewers.rst:51 msgid "" "Please note in-person attendance at PTG, Summit, mid-cycles, and other code " "sprints is not a requirement to be a core reviewer. The team will do its " "best to facilitate virtual attendance at all events. Travel is not to be " "taken lightly, and we realize the costs involved for those who attend these " "events." msgstr "" #: ../../source/contributor/core-reviewers.rst:57 msgid "Code Merge Responsibilities" msgstr "" #: ../../source/contributor/core-reviewers.rst:59 msgid "" "While everyone is encouraged to review changes, members of the core reviewer " "team have the ability to set +2/-2 on the Code-Review (CR) label as well as " "+1 on Workflow (+W) changes to these repositories. This is an extra level of " "responsibility not to be taken lightly. Correctly merging code requires not " "only understanding the code itself, but also how the code affects things " "like documentation, testing, upgrade impacts and interactions with other " "projects. It also means you pay attention to release milestones and " "understand if a patch you are merging is marked for the release, especially " "critical during the feature freeze." msgstr "" #: ../../source/contributor/core-reviewers.rst:70 msgid "Code Merge Policies" msgstr "" #: ../../source/contributor/core-reviewers.rst:72 msgid "" "Below you will find general policies on the Code-Review process and when a " "patch may be considered as ready for merge and when to +W." msgstr "" #: ../../source/contributor/core-reviewers.rst:75 msgid "" "It is the responsibility of the Core Reviewer, who reviews the change last, " "to set the +W label once a change passes the policy. Also, before setting +W " "please make sure that all dependant patches (marked with ``Depends-On`` in a " "commit message) are already merged to avoid unnecessary rechecks or case " "dependant patch(s) will fail in the gates." msgstr "" #: ../../source/contributor/core-reviewers.rst:81 msgid "" "All changes can be split into multiple categories and a slightly different " "policy may apply for each category." msgstr "" #: ../../source/contributor/core-reviewers.rst:86 msgid "New features, blueprints, design changes" msgstr "" #: ../../source/contributor/core-reviewers.rst:88 #: ../../source/contributor/core-reviewers.rst:96 msgid "" "Minimum 2 Core Reviewers, excluding the patch owner, voted +2 on Code-Review " "label" msgstr "" #: ../../source/contributor/core-reviewers.rst:90 msgid "" "Voted Code-Reviewers should be representing minimum 2 different " "organizations or be unaffiliated for diversity reasons" msgstr "" #: ../../source/contributor/core-reviewers.rst:94 msgid "Bug fixes, version bumps" msgstr "" #: ../../source/contributor/core-reviewers.rst:98 #: ../../source/contributor/core-reviewers.rst:113 msgid "" "It is allowed for all voted Core Reviewers to be affilated with the same " "organization" msgstr "" #: ../../source/contributor/core-reviewers.rst:102 msgid "Automated (bot) changes" msgstr "" #: ../../source/contributor/core-reviewers.rst:104 #: ../../source/contributor/core-reviewers.rst:120 msgid "" "Minimum 1 Core Reviewer, excluding the patch owner, voted +2 on Code-Review " "label" msgstr "" #: ../../source/contributor/core-reviewers.rst:109 msgid "Backports to stable branches" msgstr "" #: ../../source/contributor/core-reviewers.rst:111 msgid "" "Minimum 2 Core Reviewers, *including* the patch owner, voted +2 on Code-" "Review label." msgstr "" #: ../../source/contributor/core-reviewers.rst:118 msgid "Backports to unmaintained branches" msgstr "" #: ../../source/contributor/distributions.rst:3 msgid "Distribution support" msgstr "" #: ../../source/contributor/distributions.rst:8 msgid "Supported distributions" msgstr "" #: ../../source/contributor/distributions.rst:10 msgid "" "The list of supported distributions can be found in the :deploy_guide:" "`Deployment Guide `" msgstr "" #: ../../source/contributor/distributions.rst:14 msgid "Minimum requirements for OpenStack-Ansible roles" msgstr "" #: ../../source/contributor/distributions.rst:16 msgid "" "Existing and new distributions are expected to meet the following " "requirements in order for them to be accepted in the individual OpenStack-" "Ansible roles:" msgstr "" #: ../../source/contributor/distributions.rst:19 msgid "Pass functional tests" msgstr "" #: ../../source/contributor/distributions.rst:22 msgid "Graduation" msgstr "" #: ../../source/contributor/distributions.rst:24 msgid "" "For a distribution to be considered supported by the OpenStack-Ansible " "project, it has to meet the following minimum requirements:" msgstr "" #: ../../source/contributor/distributions.rst:27 msgid "" "The necessary steps for bootstrapping the operating system have to be " "documented in the :deploy_guide:`Deployment Guide `." msgstr "" #: ../../source/contributor/distributions.rst:29 msgid "" "The integration repository contains at least one job which passes the " "Temptest testing framework." msgstr "" #: ../../source/contributor/distributions.rst:33 msgid "Voting" msgstr "" #: ../../source/contributor/distributions.rst:35 msgid "" "Distributions can be promoted to voting jobs on individual roles once they " "move to the `Graduation` phase and their stability has been confirmed by the " "core OpenStack-Ansible developers. Similar to this, voting can also be " "enabled in the integration repository for all the scenarios or a specific " "one." msgstr "" #: ../../source/contributor/index.rst:3 msgid "Developer Documentation" msgstr "" #: ../../source/contributor/index.rst:5 msgid "" "In this section, you will find documentation relevant to developing " "OpenStack-Ansible." msgstr "" #: ../../source/contributor/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/contributor/index.rst:13 msgid "For user guides, see the :dev_docs:`User Guide `." msgstr "" #: ../../source/contributor/index.rst:15 msgid "" "For information on how to manage and operate OpenStack-Ansible, see the see " "the :dev_docs:`Operations Guide `." msgstr "" #: ../../source/contributor/index.rst:18 msgid "" "For in-depth technical information, see the :dev_docs:`OpenStack-Ansible " "Reference `." msgstr "" #: ../../source/contributor/index.rst:22 msgid "Contents:" msgstr "" #: ../../source/contributor/periodic-work.rst:5 msgid "Periodic Work" msgstr "" #: ../../source/contributor/periodic-work.rst:8 msgid "Releasing" msgstr "" #: ../../source/contributor/periodic-work.rst:10 msgid "Our release frequency is discussed in :ref:`reference_release`." msgstr "" #: ../../source/contributor/periodic-work.rst:13 msgid "OSA CLI tooling" msgstr "" #: ../../source/contributor/periodic-work.rst:15 msgid "" "OpenStack-Ansible used to bump everything in a single script, which made it " "hard to maintain, and was very branch specific. It made it hard for users to " "consume either an update of the upstream shas, or to bump roles with their " "own pace." msgstr "" #: ../../source/contributor/periodic-work.rst:20 msgid "" "Since then, the OpenStack-Ansible has agreed to provide more metadata " "necessary for releasing into the openstack-ansible code tree. This allowed " "the tooling for releasing to be more flexible, and lighter, over time." msgstr "" #: ../../source/contributor/periodic-work.rst:25 msgid "" "Now, all the functions are separated, and included into a branch independent " "tooling, `osa_cli_releases`." msgstr "" #: ../../source/contributor/periodic-work.rst:30 msgid "You can install the latest version of this tooling by running:" msgstr "" #: ../../source/contributor/periodic-work.rst:37 msgid "" "This tooling can then be called using ``osa releases``. Each subcommand " "contains help by default." msgstr "" #: ../../source/contributor/periodic-work.rst:41 msgid "Updating upstream SHAs" msgstr "" #: ../../source/contributor/periodic-work.rst:43 msgid "" "The dependencies for OpenStack-Ansible are updated through the use of ``osa " "releases bump_upstream_shas``. This script updates the project's pinned " "SHAs, located in the ``inventory/group_vars//source_git.yml`` " "file, based on their ``_git_track_branch`` value." msgstr "" #: ../../source/contributor/periodic-work.rst:51 msgid "Updating OpenStack-Ansible roles" msgstr "" #: ../../source/contributor/periodic-work.rst:53 msgid "" "Updating the roles to their latest version per branch is done through ``osa " "releases bump_roles``." msgstr "" #: ../../source/contributor/periodic-work.rst:56 msgid "This can do multiple things:" msgstr "" #: ../../source/contributor/periodic-work.rst:58 msgid "" "Freeze ansible-role-requirements to their latest SHAs for the branch they " "are tracking." msgstr "" #: ../../source/contributor/periodic-work.rst:60 msgid "Copy release notes relevant to the freeze." msgstr "" #: ../../source/contributor/periodic-work.rst:61 msgid "Unfreeze of master." msgstr "" #: ../../source/contributor/periodic-work.rst:63 msgid "" "Master doesn't get frozen, unless explicitly asked for it for release " "milestones, using the command ``osa releases freeze_roles_for_milestone``" msgstr "" #: ../../source/contributor/periodic-work.rst:67 msgid "Updating required collections" msgstr "" #: ../../source/contributor/periodic-work.rst:69 msgid "" "Updating collections to their latest version is done through ``osa releases " "bump_collections``." msgstr "" #: ../../source/contributor/periodic-work.rst:72 msgid "" "Please note, that only collections with type `git` are supported. Ones, that " "are installed from Ansible Galaxy should be bumped manually." msgstr "" #: ../../source/contributor/periodic-work.rst:77 msgid "Check current pins status" msgstr "" #: ../../source/contributor/periodic-work.rst:79 msgid "" "You can check the current PyPI pins that are used in openstack-ansible " "repository by running ``osa releases check_pins``. This will display a " "table, showing the current pin in OSA, and what is available upstream on " "PyPI." msgstr "" #: ../../source/contributor/periodic-work.rst:84 msgid "" "This doesn't patch the ``global-requirements-pins``, as this should be a " "manual operation. See the :ref:`cycle-checklist` to know when to bump the " "global-requirements-pins." msgstr "" #: ../../source/contributor/periodic-work.rst:89 msgid "Adding patch in releases repo" msgstr "" #: ../../source/contributor/periodic-work.rst:91 msgid "" "When the patches to update SHAs and roles have landed, you can propose the " "parent SHA as a release in the releases repo." msgstr "" #: ../../source/contributor/periodic-work.rst:94 msgid "" "This can be done using the ``new-release`` command, and then editing the SHA " "used for openstack-ansible. See also `new_releases page`_ for an explanation " "of this command." msgstr "" #: ../../source/contributor/periodic-work.rst:98 msgid "" "Please note that branches before Stein will require cleanup of the YAML file " "generated by new_releases, as it will contain ALL the roles and openstack-" "ansible repo SHAs. We have decided to NOT tag the roles anymore, so you will " "need to remove all the lines which are not relevant to the `openstack-" "ansible` repository." msgstr "" #: ../../source/contributor/periodic-work.rst:108 msgid "Trasition releases to Extended Maintenance" msgstr "" #: ../../source/contributor/periodic-work.rst:110 msgid "" "With migrating a release to `Extended Maintenance`_ (EM) status no future " "releases of the release are possible. With that, a new tag -em is " "created and it must be based on the latest numeric release." msgstr "" #: ../../source/contributor/periodic-work.rst:114 msgid "To transition a release to Extended Maintenance we need to:" msgstr "" #: ../../source/contributor/periodic-work.rst:116 msgid "Wait until all upstream repositories will transition to EM" msgstr "" #: ../../source/contributor/periodic-work.rst:118 msgid "Update OpenStack-Ansible roles normally" msgstr "" #: ../../source/contributor/periodic-work.rst:120 msgid "" "Update ``_git_install_branch`` to be ``-em`` instead of " "the SHA." msgstr "" #: ../../source/contributor/periodic-work.rst:123 msgid "Propose a new numeric release to ``openstack/releases`` repository" msgstr "" #: ../../source/contributor/periodic-work.rst:125 msgid "" "Propose to create a ``-em`` tag with the same SHA as previous " "numeric release has." msgstr "" #: ../../source/contributor/periodic-work.rst:128 msgid "" "Once EM tag is created, switch ``version`` field in ansible-role-" "requirements.yml to track ``stable/``." msgstr "" #: ../../source/contributor/periodic-work.rst:131 msgid "" "Update ``index.rst`` for master branch to reflect support status of the " "release" msgstr "" #: ../../source/contributor/periodic-work.rst:138 msgid "Trasition releases to End Of Life" msgstr "" #: ../../source/contributor/periodic-work.rst:140 msgid "" "With releases reaching `End Of Life`_ (EOL), a new tag ``-eol`` is " "created, after which branch will be deleted. Projects are free to EOL their " "branches anytime, after coordinated migration to EM is completed. Due to " "this we don't track ``stable/`` branch for upstream services for " "EM, but only for our roles. At the same time there is a coordinated " "deadline, when all projects must EOL their old branches." msgstr "" #: ../../source/contributor/periodic-work.rst:148 msgid "To transition a release to End Of Life we need to:" msgstr "" #: ../../source/contributor/periodic-work.rst:150 msgid "Create a -eol tag for OpenStack-Ansible Roles" msgstr "" #: ../../source/contributor/periodic-work.rst:152 msgid "" "Switch ansible-role-requirements.yml ``version`` field to -eol tag " "from stable/ branch." msgstr "" #: ../../source/contributor/periodic-work.rst:155 msgid "Wait for all projects to EOL" msgstr "" #: ../../source/contributor/periodic-work.rst:157 msgid "" "Update ``_git_install_branch`` variables to use -eol tag " "instead of SHAs." msgstr "" #: ../../source/contributor/periodic-work.rst:160 msgid "Create a -eol tag for OpenStack-Ansible repository" msgstr "" #: ../../source/contributor/periodic-work.rst:162 msgid "Update release support status in index.rst on the master branch." msgstr "" #: ../../source/contributor/periodic-work.rst:171 msgid "Development cycle checklist" msgstr "" #: ../../source/contributor/periodic-work.rst:173 msgid "" "On top of the normal cycle goals, a contributor can help the OpenStack-" "Ansible development team by performing one of the following recurring tasks:" msgstr "" #: ../../source/contributor/periodic-work.rst:176 msgid "By milestone 1:" msgstr "" #: ../../source/contributor/periodic-work.rst:178 msgid "Community goal acknowledgement." msgstr "" #: ../../source/contributor/periodic-work.rst:180 msgid "" "Define supported platforms release will run on. Remove testing and support " "for deprecated ones." msgstr "" #: ../../source/contributor/periodic-work.rst:183 #: ../../source/contributor/periodic-work.rst:207 #: ../../source/contributor/periodic-work.rst:213 msgid "" "Update ``global-requirements-pins``, upstream SHAs and required collections" msgstr "" #: ../../source/contributor/periodic-work.rst:185 msgid "By milestone 2:" msgstr "" #: ../../source/contributor/periodic-work.rst:187 msgid "Handle deprecations from upstream project's previous cycle." msgstr "" #: ../../source/contributor/periodic-work.rst:189 msgid "Handle OpenStack-Ansible roles deprecations from the previous cycle." msgstr "" #: ../../source/contributor/periodic-work.rst:191 msgid "" "Refresh static elements in roles. For example, update a specific version of " "the software packages." msgstr "" #: ../../source/contributor/periodic-work.rst:194 msgid "" "Update release-versioned components such as Octavia test ampohora image and " "Ironic IPA image/kernel." msgstr "" #: ../../source/contributor/periodic-work.rst:197 msgid "" "Bump ``ceph_stable_release`` to latest Ceph LTS release in the integrated " "OpenStack-Ansible repo, and inside the ``ceph_client`` role defaults." msgstr "" #: ../../source/contributor/periodic-work.rst:200 msgid "Check and bump galera versions if required." msgstr "" #: ../../source/contributor/periodic-work.rst:202 msgid "Check and bump rabbitmq versions if required." msgstr "" #: ../../source/contributor/periodic-work.rst:204 msgid "" "Check outstanding reviews and move to merge or abandon them if no longer " "valid." msgstr "" #: ../../source/contributor/periodic-work.rst:209 msgid "By milestone 3:" msgstr "" #: ../../source/contributor/periodic-work.rst:211 msgid "Implement features" msgstr "" #: ../../source/contributor/periodic-work.rst:215 msgid "After milestone 3:" msgstr "" #: ../../source/contributor/periodic-work.rst:217 msgid "Feature freeze, bug fixes, and testing improvements." msgstr "" #: ../../source/contributor/periodic-work.rst:219 msgid "Ansible version and collections freeze" msgstr "" #: ../../source/contributor/periodic-work.rst:221 msgid "After a new stable branch is created for services:" msgstr "" #: ../../source/contributor/periodic-work.rst:223 msgid "" "Update ``_git_track_branch`` variables to match the new branch name." "" msgstr "" #: ../../source/contributor/periodic-work.rst:226 msgid "" "Set all ``tempest_plugin__git_track_branch`` to None to prevent SHA " "update for them." msgstr "" #: ../../source/contributor/periodic-work.rst:229 msgid "Update upstream SHAs" msgstr "" #: ../../source/contributor/periodic-work.rst:231 msgid "After coordinated OpenStack release, before OpenStack-Ansible release:" msgstr "" #: ../../source/contributor/periodic-work.rst:233 msgid "" "Update release name in ``openstack_hosts`` repository. This will also bump " "RDO and Ubuntu Cloud Archive repositories." msgstr "" #: ../../source/contributor/periodic-work.rst:236 msgid "" "Branch all the independent repos that aren't part of the release in gerrit. " "See also the ``projects.yaml`` in the governance repo. Manually branched " "repos need extra editions, like updating the .gitreview, or the reno index. " "Please reference previous branch creations by using the appropriate topic in " "gerrit (e.g.: ``create-stein``). The previous new branch creation may be " "different as the tooling/process may have evolved, so be aware that the " "changes needed may need to be adapted." msgstr "" #: ../../source/contributor/periodic-work.rst:246 msgid "" "Switch ``trackbranch`` in ansible-role-requirements.yml to the new branch " "and update OpenStack-Ansible roles after that." msgstr "" #: ../../source/contributor/periodic-work.rst:249 msgid "" "Add supported platforms for the release to ``os-compatibility-matrix.html``" msgstr "" #: ../../source/contributor/periodic-work.rst:251 msgid "Immediately after official OpenStack-Ansible release:" msgstr "" #: ../../source/contributor/periodic-work.rst:253 msgid "" "Send a thank you note to all the contributors through the mailing lists. " "They deserve it." msgstr "" #: ../../source/contributor/periodic-work.rst:256 msgid "" "Revert changes made to ansible-role-requirements.yml and " "``*_git_track_branch`` variables to track stable branch instead of master. " "Update upstream SHAs." msgstr "" #: ../../source/contributor/periodic-work.rst:260 msgid "Reflect changes in documentation" msgstr "" #: ../../source/contributor/periodic-work.rst:262 msgid "" "Create a patch to openstack-manuals and uncomment OpenStack-Ansible in `www/" "project-data/.yaml`." msgstr "" #: ../../source/contributor/periodic-work.rst:265 msgid "" "Update index page on master to mention release date of recently released " "version as well as set its status to Maintained. With that also add a new " "release that we are about to start working on." msgstr "" #: ../../source/contributor/periodic-work.rst:269 msgid "" "Update index page on stable branch to mention only the release in topic " "rather all historical releases as well. Historical data should be present " "only on master branch." msgstr "" #: ../../source/contributor/periodic-work.rst:273 msgid "" "Update upgrade scripts and documentation to keep track on supported upgrade " "paths:" msgstr "" #: ../../source/contributor/periodic-work.rst:276 msgid "" "For SLURP releases, define ``previous_slurp_name`` in doc/source/conf.py. " "For non-SLURP - set it to ``False``." msgstr "" #: ../../source/contributor/periodic-work.rst:279 msgid "" "Update ``previous_series_name`` and ``current_series_name`` in doc/source/" "conf.py and deploy-guide/source/conf.py" msgstr "" #: ../../source/contributor/periodic-work.rst:282 msgid "Update ``UPGRADE_SOURCE_RELEASE`` in scripts/gate-check-commit.sh" msgstr "" #: ../../source/contributor/periodic-work.rst:284 msgid "" "Update ``SUPPORTED_SOURCE_SERIES`` and ``TARGET_SERIES`` in scripts/run-" "upgrade.sh. Also don't forget to cleanup irrelevant upgrade scripts." msgstr "" #: ../../source/contributor/periodic-work.rst:288 msgid "" "Add/remove required for SLURP upgrade jobs. ACTION for such jobs should be " "defined as ``upgrade_``." msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "**OpenStack-Ansible**" msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "Also called *integrated repository*" msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "External repositories" msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "" "It allows us to not repeat ourselves: it is the location of common " "playbooks, common tasks and scripts." msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "The **OpenStack-Ansible roles** repositories" msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "The **ops** repository" msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "The **specs** repository" msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "The **tests repository**" msgstr "" #: ../../source/contributor/project-onboarding.rst:0 msgid "" "The tests repository is the location for common code used in the integrated " "repo and role repos tests." msgstr "" #: ../../source/contributor/project-onboarding.rst:3 msgid "Project Onboarding" msgstr "" #: ../../source/contributor/project-onboarding.rst:5 msgid "" "This document should help you understand how to contribute to OpenStack-" "Ansible." msgstr "" #: ../../source/contributor/project-onboarding.rst:9 msgid "Project repositories" msgstr "" #: ../../source/contributor/project-onboarding.rst:11 msgid "" "The OpenStack-Ansible project has different kinds of git repositories, each " "of them with specific use cases, and different sets of practices." msgstr "" #: ../../source/contributor/project-onboarding.rst:17 msgid "Repository type or name" msgstr "" #: ../../source/contributor/project-onboarding.rst:18 msgid "Code location" msgstr "" #: ../../source/contributor/project-onboarding.rst:19 msgid "Repository purpose" msgstr "" #: ../../source/contributor/project-onboarding.rst:22 msgid "https://github.com/openstack/openstack-ansible" msgstr "" #: ../../source/contributor/project-onboarding.rst:23 msgid "Our main repository, used by deployers. Uses the other repositories." msgstr "" #: ../../source/contributor/project-onboarding.rst:26 msgid "https://github.com/openstack/openstack-ansible-os_nova" msgstr "" #: ../../source/contributor/project-onboarding.rst:27 msgid "https://github.com/openstack/openstack-ansible-os_glance" msgstr "" #: ../../source/contributor/project-onboarding.rst:28 msgid "https://github.com/openstack/ansible-role-systemd_mount" msgstr "" #: ../../source/contributor/project-onboarding.rst:29 msgid "https://github.com/openstack/ansible-config_template" msgstr "" #: ../../source/contributor/project-onboarding.rst:30 msgid "https://github.com/openstack/ansible-hardening" msgstr "" #: ../../source/contributor/project-onboarding.rst:31 #: ../../source/contributor/project-onboarding.rst:55 msgid "..." msgstr "" #: ../../source/contributor/project-onboarding.rst:32 msgid "" "Each role is in charge of deploying **exactly one** component of an " "OpenStack-Ansible deployment." msgstr "" #: ../../source/contributor/project-onboarding.rst:35 msgid "https://github.com/openstack/openstack-ansible-tests" msgstr "" #: ../../source/contributor/project-onboarding.rst:41 msgid "https://github.com/openstack/openstack-ansible-specs" msgstr "" #: ../../source/contributor/project-onboarding.rst:42 msgid "" "This repository contains all the information concerning large bodies of work " "done in OpenStack-Ansible, split by cycle." msgstr "" #: ../../source/contributor/project-onboarding.rst:46 msgid "https://github.com/openstack/openstack-ansible-ops" msgstr "" #: ../../source/contributor/project-onboarding.rst:47 msgid "" "This repository is an incubator for new projects, each project solving a " "particular operational problem. Each project has its own folder in this " "repository." msgstr "" #: ../../source/contributor/project-onboarding.rst:51 msgid "https://github.com/ceph/ceph-ansible" msgstr "" #: ../../source/contributor/project-onboarding.rst:52 msgid "https://github.com/logan2211/ansible-resolvconf" msgstr "" #: ../../source/contributor/project-onboarding.rst:53 msgid "https://github.com/willshersystems/ansible-sshd" msgstr "" #: ../../source/contributor/project-onboarding.rst:54 msgid "https://github.com/evrardjp/ansible-keepalived" msgstr "" #: ../../source/contributor/project-onboarding.rst:56 msgid "" "OpenStack-Ansible is not re-inventing the wheel, and tries to reuse as much " "as possible existing roles. A bugfix for one of those repositories must be " "handled to these repositories' maintainers." msgstr "" #: ../../source/contributor/project-onboarding.rst:62 msgid "How to contribute on code or issues" msgstr "" #: ../../source/contributor/project-onboarding.rst:64 msgid "" "For contributing code and documentation, you must follow the OpenStack " "practices. Nothing special is required for OpenStack-Ansible." msgstr "" #: ../../source/contributor/project-onboarding.rst:67 msgid "" "See also the `OpenStack developers getting started page`_. and our :ref:" "`contributor guidelines` before hacking." msgstr "" #: ../../source/contributor/project-onboarding.rst:70 msgid "" "For helping on or submitting bugs, you must have an account on ubuntu " "Launchpad. All our repositories share the same `Launchpad project`_." msgstr "" #: ../../source/contributor/project-onboarding.rst:74 msgid "" "Please check our :ref:`bug report` and :ref:`bug " "triage` processes." msgstr "" #: ../../source/contributor/project-onboarding.rst:77 msgid "" "Easy to fix bugs are marked with the tag *low hanging fruit*, and should be " "the target of first time contributors." msgstr "" #: ../../source/contributor/project-onboarding.rst:80 msgid "" "For sharing your user experience, stories, and helping other users, please " "join us in our :ref:`IRC channel`." msgstr "" #: ../../source/contributor/project-onboarding.rst:83 msgid "" "The OpenStack-Ansible project has recurring tasks that need attention, like " "releasing, or other code duties. See our page :ref:`Periodic " "work`." msgstr "" #: ../../source/contributor/project-onboarding.rst:91 msgid "Community communication channels" msgstr "" #: ../../source/contributor/project-onboarding.rst:105 msgid "" "The OpenStack-Ansible community communicates a lot through IRC, in the " "#openstack-ansible channel, on OFTC. This channel is logged, and its logs " "are published on http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/" "." msgstr "" #: ../../source/contributor/project-onboarding.rst:110 msgid "" "Weekly meetings are held in our IRC channel. The schedule and logs can be " "found on http://eavesdrop.openstack.org/" "#OpenStack_Ansible_Deployment_Meeting. Next meeting agenda can be found on " "our `Meetings wiki page `_." msgstr "" #: ../../source/contributor/project-onboarding.rst:119 msgid "" "A member of the OpenStack-Ansible community should monitor the **OpenStack-" "discuss** `mailing lists`_." msgstr "" #: ../../source/contributor/testing.rst:5 msgid "Testing" msgstr "" #: ../../source/contributor/testing.rst:8 msgid "Adding tests to a new role" msgstr "" #: ../../source/contributor/testing.rst:10 msgid "Each of the role tests is in its tests/ folder." msgstr "" #: ../../source/contributor/testing.rst:12 msgid "This folder contains at least the following files:" msgstr "" #: ../../source/contributor/testing.rst:14 msgid "``test.yml`` (\"super\" playbook acting as test router to sub-playbooks)" msgstr "" #: ../../source/contributor/testing.rst:15 msgid "" "``-overrides.yml``. This var file is automatically loaded by our " "shell script in our `tests repository`_." msgstr "" #: ../../source/contributor/testing.rst:17 msgid "" "``inventory``. A static inventory for role testing. It's possible some roles " "have multiple inventories. See for example the neutron role with its " "``lxb_inventory``." msgstr "" #: ../../source/contributor/testing.rst:20 msgid "" "``group_vars`` and ``host_vars``. These folders will hold override the " "necessary files for testing. For example, this is where you override the IP " "addresses, IP ranges, and ansible connection details." msgstr "" #: ../../source/contributor/testing.rst:23 msgid "" "``ansible-role-requirements.yml``. This should be fairly straightforward: " "this file contains all the roles to clone before running your role. The " "roles' relative playbooks will have to be listed in the ``test.yml`` file. " "However, keep in mind to NOT re-invent the wheel. For example, if your role " "needs keystone, you don't need to create your own keystone install playbook, " "because we have a generic keystone install playbook in the `tests " "repository`." msgstr "" #: ../../source/contributor/testing.rst:30 msgid "" "Only add a ``zuul.d`` folder when your role is imported into the openstack-" "ansible namespace." msgstr "" #: ../../source/contributor/testing.rst:36 msgid "Extending tests of an existing role" msgstr "" #: ../../source/contributor/testing.rst:38 msgid "" "Modify the tox.ini to add your new scenario. If required, you can override " "the inventory, and/or the variable files." msgstr "" #: ../../source/contributor/testing.rst:40 msgid "" "Add a new non-voting job in ``zuul.d/jobs.yaml``, and wire it in the project " "tests file ``zuul.d/project.yaml``." msgstr "" #: ../../source/contributor/testing.rst:46 msgid "Improve testing with tempest" msgstr "" #: ../../source/contributor/testing.rst:48 msgid "" "Once the initial convergence is working and the services are running, the " "role development should focus on implementing some level of functional " "testing." msgstr "" #: ../../source/contributor/testing.rst:52 msgid "" "Ideally, the functional tests for an OpenStack role should make use of " "Tempest to execute the functional tests. The ideal tests to execute are " "scenario tests as they test the functions that the service is expected to do " "in a production deployment. In the absence of any scenario tests for the " "service a fallback option is to implement the smoke tests instead." msgstr "" #: ../../source/contributor/testing.rst:59 msgid "" "If no tempest is provided, some other functional testing should be done. For " "APIs, you can probably check the HTTP response codes, with specially crafted " "requests." msgstr "" #: ../../source/contributor/testing.rst:66 msgid "Running tests locally" msgstr "" #: ../../source/contributor/testing.rst:69 msgid "Linting" msgstr "" #: ../../source/contributor/testing.rst:71 msgid "" "Python coding conventions are tested using `PEP8`_, with the following " "convention exceptions:" msgstr "" #: ../../source/contributor/testing.rst:74 msgid "F403 - 'from ansible.module_utils.basic import \\*'" msgstr "" #: ../../source/contributor/testing.rst:76 #: ../../source/contributor/testing.rst:95 #: ../../source/contributor/testing.rst:103 #: ../../source/contributor/testing.rst:111 msgid "Testing may be done locally by executing:" msgstr "" #: ../../source/contributor/testing.rst:82 msgid "" "Bash coding conventions are tested using `Bashate`_, with the following " "convention exceptions:" msgstr "" #: ../../source/contributor/testing.rst:85 msgid "" "E003: Indent not multiple of 4. We prefer to use multiples of 2 instead." msgstr "" #: ../../source/contributor/testing.rst:87 msgid "" "and use jinja templating, this is very difficult to achieve. It is still " "considered a preference and should be a goal to improve readability, within " "reason." msgstr "" #: ../../source/contributor/testing.rst:88 msgid "" "E006: Line longer than 79 columns. As many scripts are deployed as templates" msgstr "" #: ../../source/contributor/testing.rst:91 msgid "" "as templates and use jinja templating, this will often fail. This test is " "reasonably safely ignored as the syntax error will be identified when " "executing the resulting script." msgstr "" #: ../../source/contributor/testing.rst:93 msgid "" "E040: Syntax error determined using `bash -n`. As many scripts are deployed" msgstr "" #: ../../source/contributor/testing.rst:101 msgid "Ansible is lint tested using `ansible-lint`_." msgstr "" #: ../../source/contributor/testing.rst:109 msgid "Ansible playbook syntax is tested using ansible-playbook." msgstr "" #: ../../source/contributor/testing.rst:117 msgid "A consolidated set of all lint tests may be done locally by executing:" msgstr "" #: ../../source/contributor/testing.rst:128 msgid "Documentation building" msgstr "" #: ../../source/contributor/testing.rst:130 msgid "" "Documentation is developed in reStructuredText_ (RST) and compiled into HTML " "using Sphinx." msgstr "" #: ../../source/contributor/testing.rst:133 msgid "Documentation may be built locally by executing:" msgstr "" #: ../../source/contributor/testing.rst:141 msgid "" "The OpenStack-Ansible integrated repo also has an extra documentation " "building process, to build the deployment guide." msgstr "" #: ../../source/contributor/testing.rst:144 msgid "This guide may be built locally by executing:" msgstr "" #: ../../source/contributor/testing.rst:151 msgid "Release notes building" msgstr "" #: ../../source/contributor/testing.rst:153 msgid "" "Release notes are generated using the `the reno tool`_ and compiled into " "HTML using Sphinx." msgstr "" #: ../../source/contributor/testing.rst:156 msgid "Release notes may be built locally by executing:" msgstr "" #: ../../source/contributor/testing.rst:166 msgid "" "The ``releasenotes`` build argument only tests committed changes. Ensure " "your local changes are committed before running the ``releasenotes`` build." msgstr "" #: ../../source/contributor/testing.rst:171 msgid "Roles functional or scenario testing" msgstr "" #: ../../source/contributor/testing.rst:173 msgid "To run a functional test of the role, execute:" msgstr "" #: ../../source/contributor/testing.rst:182 msgid "Testing a new role with an AIO" msgstr "" #: ../../source/contributor/testing.rst:184 msgid "" "Include your role on the deploy host. See also :ref:`extend_osa_roles`." msgstr "" #: ../../source/contributor/testing.rst:186 msgid "" "Perform any other host preparation (such as the tasks performed by the " "``bootstrap-aio.yml`` playbook). This includes any preparation tasks that " "are particular to your service." msgstr "" #: ../../source/contributor/testing.rst:189 msgid "" "Generate files to include your service in the Ansible inventory using ``env." "d`` and ``conf.d`` files for use on your deploy host." msgstr "" #: ../../source/contributor/testing.rst:192 msgid "" "You can follow examples from other roles, making the appropriate " "modifications being sure that group labels in ``env.d`` and ``conf.d`` files " "are consistent." msgstr "" #: ../../source/contributor/testing.rst:196 msgid "" "A description of how these work can be found in :ref:`inventory-confd` and :" "ref:`inventory-envd`." msgstr "" #: ../../source/contributor/testing.rst:199 msgid "" "Generate secrets, if any, as described in the :deploy_guide:`Configure " "Service Credentials `. You " "can append your keys to an existing ``user_secrets.yml`` file or add a new " "file to the ``openstack_deploy`` directory to contain them. Provide " "overrides for any other variables you will need at this time as well, either " "in ``user_variables.yml`` or another file." msgstr "" #: ../../source/contributor/testing.rst:206 msgid "See also our :ref:`user-overrides` page." msgstr "" #: ../../source/contributor/testing.rst:208 msgid "" "Any secrets required for the role to work must be noted in the ``etc/" "openstack_deploy/user_secrets.yml`` file for reuse by other users." msgstr "" #: ../../source/contributor/testing.rst:211 msgid "" "If your service is installed from source or relies on python packages which " "need to be installed from source, specify a repository for the source code " "of each requirement by adding a file to your deploy host under ``inventory/" "group_vars//source_git.yml`` in the OpenStack-Ansible source " "repository and following the pattern of files currently in that directory. " "You could also simply add an entry to an existing file there." msgstr "" #: ../../source/contributor/testing.rst:219 msgid "" "Make any required adjustments to the load balancer configuration (e.g. " "modify ``inventory/group_vars/all/haproxy.yml`` in the OpenStack-Ansible " "source repository on your deploy host) so that your service can be reached " "through a load balancer, if appropriate, and be sure to run the ``haproxy-" "install.yml`` play later so your changes will be applied. Please note, you " "can also use ``haproxy_extra_services`` variable if you don't want to " "provide your service as default for everyone." msgstr "" #: ../../source/contributor/testing.rst:227 msgid "" "Put together a service install playbook file for your role. This can also be " "modeled from any existing service playbook that has similar dependencies to " "your service (database, messaging, storage drivers, container mount points, " "etc.). A common place to keep playbook files in a Galaxy role is in an " "``examples`` directory off the root of the role. If the playbook is meant " "for installing an OpenStack service, name it ``os--install.yml`` " "and target it at the appropriate group defined in the service ``env.d`` file." " It is crucial that the implementation of the service is optional and that " "the deployer must opt-in to the deployment through the population of a host " "in the applicable host group. If the host group has no hosts, Ansible skips " "the playbook's tasks automatically." msgstr "" #: ../../source/contributor/testing.rst:240 msgid "" "Any variables needed by other roles to connect to the new role, or by the " "new role to connect to other roles, should be implemented in ``inventory/" "group_vars``. The group vars are essentially the glue which playbooks use to " "ensure that all roles are given the appropriate information. When group vars " "are implemented it should be a minimum set to achieve the goal of " "integrating the new role into the integrated build." msgstr "" #: ../../source/contributor/testing.rst:248 msgid "" "Documentation must be added in the role to describe how to implement the new " "service in an integrated environement. This content must adhere to the :ref:" "`documentation`. Until the role has integrated functional testing " "implemented (see also the Role development maturity paragraph), the " "documentation must make it clear that the service inclusion in OpenStack-" "Ansible is experimental and is not fully tested by OpenStack-Ansible in an " "integrated build. Alternatively, an user story can be created." msgstr "" #: ../../source/contributor/testing.rst:257 msgid "" "A feature release note must be added to announce the new service " "availability and to refer to the role documentation for further details. " "This content must adhere to the :ref:`documentation`." msgstr "" #: ../../source/contributor/testing.rst:262 msgid "" "It must be possible to execute a functional, integrated test which executes " "a deployment in the same way as a production environment. The test must " "execute a set of functional tests using Tempest. This is the required last " "step before a service can remove the experimental warning from the " "documentation." msgstr "" #: ../../source/contributor/testing.rst:268 msgid "" "If you adhere to the pattern of isolating your role's extra deployment " "requirements (secrets and var files, HAProxy yml fragments, repo_package " "files, etc.) in their own files it makes it easy for you to automate these " "additional steps when testing your role." msgstr "" #: ../../source/contributor/testing.rst:274 msgid "Integrated repo functional or scenario testing" msgstr "" #: ../../source/contributor/testing.rst:276 msgid "" "To test the integrated repo, follow the :deploy_guide:`Deployment Guide " "`" msgstr "" #: ../../source/contributor/testing.rst:279 msgid "" "Alternatively, you can check the :ref:`aio guide`, or even " "run the gate wrapper script, named ``scripts/gate-check-commit.sh``, " "described below." msgstr "" #: ../../source/contributor/testing.rst:284 msgid "The OpenStack Infrastructure automated tests" msgstr "" #: ../../source/contributor/testing.rst:286 msgid "" "There should be no difference between running tests in the openstack " "infrastructure, versus running locally." msgstr "" #: ../../source/contributor/testing.rst:289 msgid "" "The tests in the openstack infrastructure are triggered by jobs defined in " "each repo ``zuul.d`` folder." msgstr "" #: ../../source/contributor/testing.rst:292 msgid "See also the `zuul user guide`_." msgstr "" #: ../../source/contributor/testing.rst:294 msgid "" "However, for reliability purposes, a few variables are defined to point to " "the OpenStack infra pypi and packages mirrors." msgstr "" #: ../../source/contributor/testing.rst:299 msgid "" "The integrated repo functional test is using the ``scripts/gate-check-commit." "sh`` script, which receives arguments from the zuul run playbook definition." msgstr "" #: ../../source/contributor/testing.rst:303 msgid "" "While this script is primarily developed and maintained for use in OpenStack-" "CI, it can be used in other environments." msgstr "" #: ../../source/contributor/testing.rst:309 msgid "Role development maturity" msgstr "" #: ../../source/contributor/testing.rst:311 msgid "" "A role may be fully mature, even if it is not integrated in the ``openstack-" "ansible`` repository. The maturity depends on its testing levels." msgstr "" #: ../../source/contributor/testing.rst:315 msgid "A role can be in one of the four maturity levels:" msgstr "" #: ../../source/contributor/testing.rst:317 msgid "``Complete``" msgstr "" #: ../../source/contributor/testing.rst:318 msgid "``Incubated``" msgstr "" #: ../../source/contributor/testing.rst:319 msgid "``Unmaintained``" msgstr "" #: ../../source/contributor/testing.rst:320 msgid "``Retired``" msgstr "" #: ../../source/contributor/testing.rst:322 msgid "Here are a series of rules that define maturity levels:" msgstr "" #: ../../source/contributor/testing.rst:324 msgid "A role can be retired at any time if it is not relevant anymore." msgstr "" #: ../../source/contributor/testing.rst:325 msgid "A role can be ``Incubated`` for maximum 2 cycles." msgstr "" #: ../../source/contributor/testing.rst:326 msgid "" "An ``Incubated`` role that passes functional testing will be upgraded to the " "``Complete`` status, and cannot return in ``Incubated`` status." msgstr "" #: ../../source/contributor/testing.rst:328 msgid "" "An ``Incubated`` role that didn't implement functional testing in the six " "month timeframe will become ``Unmaintained``." msgstr "" #: ../../source/contributor/testing.rst:330 msgid "" "A role in ``Complete`` status can be downgraded to ``Unmaintained``. status, " "according to the maturity downgrade procedure." msgstr "" #: ../../source/contributor/testing.rst:334 msgid "Maturity downgrade procedure" msgstr "" #: ../../source/contributor/testing.rst:336 msgid "" "If a role has failed periodics or gate test for two weeks, a bug should be " "filed, and a message to the mailing list will be sent, referencing the bug." msgstr "" #: ../../source/contributor/testing.rst:340 msgid "" "The next community meeting should discuss about role deprecation, and if no " "contributor comes forward to fix the role, periodic testing will be turned " "off, and the role will move to an ``unmaintained`` state." msgstr "" #: ../../source/contributor/testing.rst:348 msgid "Maturity Matrix" msgstr "" #: ../../source/contributor/testing.rst:350 msgid "" "All of the OpenStack-Ansible roles do not have the same level of maturity " "and testing." msgstr "" #: ../../source/contributor/testing.rst:353 msgid "Here is a dashboard of the current status of the roles:" msgstr ""