openstack/training-guides
Code Issues Proposed changes

Merge "[upstream] Remove Duplicated Content"

Browse Source
This commit is contained in:
Zuul 2018-05-17 13:59:30 +00:00 committed by Gerrit Code Review
commit a048287c09
6 changed files with 37 additions and 870 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
doc/upstream-training/source/slides/howitsmade-events.rst
View File

@ -9,84 +9,19 @@ OpenStack Events
.. note::
Tags: [management] [operator] [user] [new_dev] [dev]
Regional Events
===============
- OpenStack Days
- OpenStack Birthday Celebration
- User Group Meetups
OpenStack Days
==============
- Regional 'Mini-Summit'
- Hosted annually by local OpenStack User Groups and companies
- Endorsed by the Foundation
- Growing in number (26 in 2016)
Exercise 1
==========
- Look up an OpenStack Days event close to where you live that you would be
interested in attending
OpenStack Birthday Celebration
==============================
- Held by local groups to celebrate another year of OpenStack
- 2017 was 7th birthday of OpenStack
User Group Meetups
==================
- Smaller scale than OpenStack Days Events
- Some are more development focused while others are more user and
ops focused
- https://groups.openstack.org/
Global Events and Releases
==========================
- Each Release has two main events: PTG and the Summit
- The PTG is scheduled around the start of a release to plan release goals
- Summits take place around the middle of a release to exhibit accomplishments
and get feedback from users on the most recent release
Project Team Gathering (PTG)
============================
- A gathering of projects teams and contributors
- Dedicated and detailed technical discussions
- Useful for participants if they are already working with a
project team
- Not good as an entry point
.. note
https://www.openstack.org/ptg
https://www.openstack.org/ptg/ptgfaq/
Exercise 2
==========
- Look up the location and dates of the next PTG
Summit & Forum
==============
Exercise 3
==========
- The summit is a biannual conference with keynotes, presentations,
and panel discussions
- Forum:
- User focused discussions at the Forum to collect feedback
for developers
- Better entry point for new contributors finding their place in the
community
Types of sessions at the Forum
==============================
- Fishbowls: Open moderated discussions
- Project Onboarding Sessions: A place for new contributors to ask
questions and get to know other contributors to the project
- Hacking Rooms: Reservable rooms for projects to gather for technical
discussions
- Look up the location and dates of the next Summit/Forum.

231
doc/upstream-training/source/slides/howitsmade-governance.rst
View File

@ -9,232 +9,21 @@ OpenStack Governance
.. note::
Tags: [management] [new_dev] [dev]
OpenStack Foundation
====================
- Nonprofit foundation created to "develop, support, protect, and promote"
OpenStack
- Individual members: all of us
- Institutional members: Platinum and Gold sponsors
- Further supporting companies and organizations
- Multi-layer group of leadership
- Board of directors
- Technical Committee
- User Committee
Board of Directors
==================
- Strategic and financial oversight
- Representatives are elected from
- Platinum member companies
- Gold member companies
- Individual Foundation members
.. note::
- Each Platinum member can delegate one member
- Gold members can delegate the same amount of members as Platinum members
- by majority vote of all Gold Members
- Individual members elect the same amount
For more info see Article IV of `Bylaws of the OpenStack Foundation
<https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/>`_
Technical Committee ("TC")
==========================
- Provides
- Oversight over the OpenStack projects
- Technical leadership
- Enforces OpenStack ideals like: Openness, Transparency, Commonality,
Integration and Quality
- Handles cross-project related topics and issues
- Composed of 13 OpenStack Foundation Individual members
- directly elected by ATC's
- The TC Chair is proposed by the TC members
.. note::
- `OpenStack Technical Comittee page <https://governance.openstack.org/tc/>`_
- `OpenStack Technical Comittee Charter <https://governance.openstack.org/tc/reference/charter.html>`_
- `List of TC members <https://www.openstack.org/foundation/tech-committee/>`_
User Committee ("UC")
=====================
- Represents OpenStack users
- Gathers feedback and consolidates requirements
- Further details are in a later session
.. note::
- `OpenStack User Committee page <https://governance.openstack.org/uc/index.html>`_
- `Members of OpenStack User Comittee <https://www.openstack.org/foundation/user-committee/>`_
Exercise
========
- Find the current members of the Board of Directors, TC and UC
- Find the latest election results for Board of Directors, TC and UC.
Also find where the OpenStack election procedures are documented.
- Post the information and web sites in the Upstream Collaboration Training
Etherpad.
.. note::
- The election of Board of Directors is announced via
`Board election page <https://www.openstack.org/election/>`_,
and the election result can be seen in
`Foundation mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation>`_.
- TC (+PTL) candidates and election results are available on
`Governance - Election page <https://governance.openstack.org/election/>`_,
and shared through `openstack-dev mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>`_.
- UC election information is available though
`User-committee mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee>`_.
OpenStack Project Teams
=======================
- Teams of people who
- Produce *deliverables* to achieve a clearly stated *objective*
- Using the common tools (code repository, bug tracker, CI system, etc.)
- Work towards OpenStack's mission
- Teams in OpenStack can be freely created as they are needed
- Official project teams fall under the TC's authority and are led by a
Project Team Lead and Core Team Members
- The official list of projects:
- https://governance.openstack.org/reference/projects/
.. note::
- Source file is hosted in the `governance repository <https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml>`_
Active Technical Contributor (ATC)
==================================
- Subset of the Foundation Individual Members
- Committed a change over the last two 6-month release cycles
- Code or documentation contribution to any of the official project
repositories
- Individual members, can be granted ATC status by the PTL of an official
project and TC approval. This is called extra-ATC status.
- An OpenStack wide status
- TC members are elected by the ATC's
.. note::
- ATC's should be proposed into `projects.yaml
<https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml>`_
under ``extra-atcs`` of the actual project, but not after the
`Extra-ATC's deadline <https://releases.openstack.org/pike/schedule.html#p-extra-atcs>`_
of the cycle expired.
Active Project Contributor (APC)
================================
- Subset of ATCs who have contributed to a specific project
- Same criteria as ATC except for contributions to a project
- OpenStack project specific status
Project Team Leads (PTLs)
=========================
- Elected from and by the group of APC's
- Each PTL candidate needs to submit PTL candidacy
- PTL responsibilities
- Manage day-to-day operations
- Drive the program goals
- Resolve technical disputes
- `Other responsibilities <https://docs.openstack.org/project-team-guide/ptl.html>`_
.. note::
- The responsibilities of a PTL also depend on the project
(Each project handles things a little differently).
Core Team Members
=================
- Have authority to merge code into a project
- Assist the PTL in driving program goals
- New Core Team members are nominated and elected by other Core Team Members
- Unlike ATC, APC and PTLs, role is not defined in the TC charter
.. note::
- Election process is more informal than PTLs.
- PTL or Core Team Member nominates a person.
- Core team membership is about merging on master, stable core membership is independent
- PTL e-mails nomination to mailing list.
- Though not defined in the TC charter like other roles above, cores
serve an important role in Project Teams.
- Person is elected if no team members object to the nomination.
Active User Contributors (AUC)
==============================
- Users with the following activities are recognized with AUC status:
- Organizers of Official OpenStack User Groups
- Active members and contributors to functional teams and/or working groups
- Moderators of any of the operators' official meet-up sessions
- Contributors to the repository under the UC governance
- Track chairs for OpenStack Summits
- Contributors to Superuser
- Active moderators on ask.openstack.org
.. note::
- `OpenStack User Committee Charter <https://governance.openstack.org/uc/reference/charter.html>`_
Exercise
========
- Determine who the current PTL is of your favorite project.
- Post their name, the project and a project goal for the next release in
the Upstream Collaboration Training Etherpad.
- Find two other cores in the project and post their names in
the Upstream Collaboration Training Etherpad.
References
Exercise 1
==========
- `Board election <https://www.openstack.org/election/>`_
- `Bylaws of the OpenStack Foundation <https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/>`_
- `Foundation mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation>`_
- `Governance - Election page <https://governance.openstack.org/election/>`_
- `List of TC members <https://www.openstack.org/foundation/tech-committee/>`_
- `Members of OpenStack User Comittee <https://www.openstack.org/foundation/user-committee/>`_
- `openstack-dev mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>`_
- `OpenStack Technical Comittee Charter <https://governance.openstack.org/tc/reference/charter.html>`_
- `OpenStack Technical Comittee page <https://governance.openstack.org/tc/>`_
- `OpenStack User Committee <https://governance.openstack.org/uc/index.html>`_
- Find the current members of the Board of Directors, TC and UC
.. note::
Exercise 2
===========
- This slide is for reference links in case people want to get more information later. Presenters
do not need to spend time on this.
- Find the latest election results for Board of Directors, TC and UC.
- Which members of these groups will be up for reelection during the
next round?
References Cont.
================
Exercise 2
==========
- `OpenStack User Committee Charter <https://governance.openstack.org/uc/reference/charter.html>`_
- `User-committee mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee>`_
- What is the difference between ATC, AUC, and APC?

99
doc/upstream-training/source/slides/howitsmade-official-projects.rst
View File

@ -1,5 +1,5 @@
===========================
Official OpenStack projects
Official OpenStack Projects
===========================
.. image:: ./_assets/os_background.png
@ -10,101 +10,14 @@ Official OpenStack projects
Tags: [management] [operator] [user] [new_dev] [dev]
Official OpenStack projects
===========================
- `Requirements <https://governance.openstack.org/reference/new-projects-requirements.html>`_
for official OpenStack projects
- Projects improve and grow independently but also strive to improve one
collaborative framework: OpenStack
- Projects APIs are documented within the project
- Testable on its own
- Dashboard (horizon) and DevStack provide plugin interface for easy
integration
- Official OpenStack projects are tracked in the
`Project Navigator <https://www.openstack.org/software/project-navigator>`_
- Big Tent was a code name for the official OpenStack projects
.. note::
- Not all projects are currently tracked in Project Navigator. The goal,
however, is for it to be an ever growing list.
Benefits of being an Official OpenStack project
===============================================
- Contributors get to vote in the Technical Committee election
- Can publish to docs.openstack.org and developer.openstack.org
- The teams get space at OpenStack Summits and Project Team Gatherings (PTG)
- Get marketing from the OpenStack Foundation
- Can participate in common programs, like mentoring and internship to help
with on boarding
- Get guidance from community members and leaders
- Its activities are under the oversight of the TC
.. note::
- PTG: https://www.openstack.org/ptg/
- `Mentoring <https://wiki.openstack.org/wiki/Mentors>`_ is run by the Women
of OpenStack group, where mentees are guided through the OpenStack processes.
- The OpenStack Foundation participates in internship programs as
`Outreachy <https://wiki.openstack.org/wiki/Outreachy>`_.
- Official OpenStack projects can participate by offering topics and mentors
for the interns who sign up for this program.
Core and Optional Services
==========================
- Core services are OpenStack projects and essential in every OpenStack-powered
IaaS cloud or product
- Optional services are also OpenStack projects but not necessarily needed to
operate OpenStack depending on use cases
.. note::
- Full list of Official OpenStack Project Teams:
https://governance.openstack.org/tc/reference/projects/index.html
Core and Optional Services
==========================
.. image:: ./_assets/official-openstack-projects.png
:scale: 90 %
Exercise
========
Exercise 1
==========
- Find the requirements that must be met to be an official OpenStack project
- Tags can be associated with projects. Find out what tags are and find the
current list of available tags.
.. note::
- https://governance.openstack.org/tc/reference/new-projects-requirements.html
- An official project is aligned with the OpenStack Mission if it
- has a clear and defined scope
- provides a cloud infrastructure service or directly builds on an
existing OpenStack cloud infrastructure service
- Follows/observes the four opens: Source, Community, Development, Design
- https://governance.openstack.org/reference/tags/index.html
- Describe the artifacts created by an OpenStack community team
- Processes followed, release management, etc.
References
Exercise 2
==========
- `PTG <https://www.openstack.org/ptg/>`_
- `Mentoring <https://wiki.openstack.org/wiki/Mentors>`_
- `Internship Programs <https://wiki.openstack.org/wiki/Outreachy>`_
- `OpenStack Project Teams <https://governance.openstack.org/tc/reference/projects/index.html>`_
- `New Project Requirements <https://governance.openstack.org/tc/reference/new-projects-requirements.html>`_
- `Tags <https://governance.openstack.org/reference/tags/index.html>`_
- Tags can be associated with projects. Find out what tags are used for and
find the current list of available tags.
.. note::
- This slide is for reference links in case people want to get more information later. Presenters
do not need to spend time on this.

265
doc/upstream-training/source/slides/howitsmade-release-cycle.rst
View File

@ -9,45 +9,9 @@ OpenStack Release Cycle
.. note::
Tags: [management] [operator] [user] [new_dev] [dev]
What makes a release
====================
- Coordinated development of multiple projects
- Release process is managed by the Release Management team
- Release models
- *Common cycle with development milestones*
- Common cycle with intermediary release
- Trailing the common cycle
- Independent release model
- A given project cannot follow more than one model
.. note::
- Release management description:
https://docs.openstack.org/project-team-guide/release-management.html
- The training concentrates on the common cycle with the development
milestones as that is what most students will work with. The other types
should be described.
- Common cycle with intermediary release:
- Used for components needing more frequent releases. e.g. Oslo Libraries
- Intermediary releases can also be used to time releases near the
beginning and end of the release cycle. Horizon plug-ins do this.
- Trailing the common cycle:
- Projects dependent upon the output of a release, like packaging or
deploying OpenStack follow this model; e.g. Fuel and Kolla
- Independent release model:
- These projects may hold tools used for OpenStack but are not part of a
production release.
Exercise
========
Exercise 1
==========
- Look up the release schedule for the current and past two OpenStack
release cycles
@ -64,237 +28,24 @@ Exercise
- Post the information on the IRC channel
Common cycle with development milestones
========================================
- Project teams create their deliverables, including testing and
documentation, on a coordinated schedule
- Every cycle includes
- Planning and design activities
- Implementation work
- New features
- Bug fixes
- Testing
- Documentation
- Release preparation
- Release
Planning - Design
=================
- Design activity is a continuous effort
- Planning for a release cycle starts at the end of the previous cycle
- Face to face planning discussions happen at the Project Teams Gathering
(PTG) which is coordinated with the start of a development new cycle
- Each project team sets priorities/dates for the release
- Spec/blueprint freeze
- Prioritization of items (e.g. testing, documentation, etc.)
- Generic intention behind planning
- Take a step back
- Focus on what we want to do for the next one
Planning - Discuss
==================
- Prepare your idea for proposal to the community.
- Discuss with your project team
- PTG is a good time to propose and discuss features/fixes
- Work on feedback and comments
- Capture your idea in a spec/blueprint
.. note::
- Whether a change requires just a blueprint or spec and blueprint
depends on the complexity of the change.
- Start with a blueprint and look to the project team's core members
for guidance on whether a spec is needed.
Planning - Target
=================
- Submit the blueprints and/or specs
- Identify a target milestone
- When in the cycle you intend to complete it
- Project team helps you to identify the target milestone and register it
in the tracking tool
- The priority of the work item is set by the project team members or lead
- Feature proposal freeze
- The deadline for proposing new ideas for a release cycle
- The exact date is determined by each project team
Exercise
========
Exercise 2
==========
- Find feature proposal deadlines in the current release schedule
- Compare the deadlines between two different project teams and discuss the
differences with your group
Implementation
==============
- When your blueprint/spec is accepted
- Push code to Gerrit for review
- Upload your code as early as possible in the release cycle
- Code can be uploaded before a blueprint/spec is accepted
- Deadlines for the code to get merged
- Depends on the priority of your work item
- Set by each project team
Implementation - Milestone
==========================
- Three development milestones during a release cycle
- Make useful reference points in time to organize the development cycle
- Milestones are tagged in the repository using b1, b2 and b3
- Overall feature freeze is the third milestone
Exercise
========
Exercise 3
==========
- In addition to milestones, there are freeze dates for different activities
in the release
- Work with your group to find and discuss the different freeze activities
.. note::
- Spec freeze
- Point at which specs must be proposed and reviewed for the release.
- Feature freeze
- Code for new features is no longer accepted.
- String freeze
- Externally visible strings can no longer be changed. Helps translation
activities complete on time.
- Requirements freeze
- Requirements cannot be changed to allow downstream packagers time to
pull-in and build dependencies.
Release Candidates
==================
- After the last milestone
- Code stabilization period
- Main activities
- Test the code and file bugs
- Prioritize bugs / bug triage
- Get critical and high priority bugs fixed first
- Fix as many bugs as possible
- Finalize documentation
.. note::
- Code change during the RC phase is a balancing act
- Need to balance integrating fixes and code churn
- Critical fixes have the highest priority while more minor bug fixes may
be safer to hold for the subsequent release.
- Who is able to approve patches during the RC phase is limited.
Release candidate process
=========================
- Release Candidate 1 (RC1) is cut when all the release-critical bugs are fixed
- stable/release branch
- master branch is open for development
- Used as-is as the final release
- Additional Release Candidates created for critical bugs found during
RC testing
- (RC2, RC3, ...) with bugs targeted to it
- Repeated as many times as necessary
Release day
===========
- Last published release candidate from all Project Teams
- Published collectively as the OpenStack release
Exercise
========
Exercise 4
==========
- Find the release day for the current release
- Find where the currently released code is posted
Stable Branch
=============
- Name for a cycle that has been released
- Projects that follow some form of the 'Common' release
cycle have branches like 'stable/<release name>' in their repo
- Support phases
+------------+-----------------------------+---------------------------------+
| Phase | Time Frame | Changes Supported |
+============+=============================+=================================+
| I | First 6 months | All appropriate bug fixes |
+------------+-----------------------------+---------------------------------+
| II | 6 - 12 months after release | Only critical or security fixes |
+------------+-----------------------------+---------------------------------+
| III | More than 12 months | Only security fixes accepted |
+------------+-----------------------------+---------------------------------+
Proposing fixes to Stable Branches
==================================
- Fixes to stable must first merge to master and all intermediate branches
- Appropriate backports
- Low regression risk in stable branch
- Fixes a user visible problem
- Backport is self contained
- Inappropriate backports
- Backports of new functionality
- Changes to external HTTP APIs
- Notification, DB Schema or incompatible config file changes
Stable Branch Reviews
=====================
- Stable maintenance teams
- Each project has a subset of cores able to merge stable branch changes
- Ensure that the stable branch policies are enforced
- Ensure that backports are associated with the patch submitted to master
References
==========
- `Release management description <https://docs.openstack.org/project-team-guide/release-management.html>`_
.. note::
- This slide is for reference links in case people want to get more information later. Presenters
do not need to spend time on this.

79
doc/upstream-training/source/slides/workflow-commit-message.rst
View File

@ -9,31 +9,8 @@ Commit Messages
.. note::
Tags: [new_dev] [dev]
Commit Messages
===============
- The first thing a reviewer sees and it is as important as the code
- Brief explanation with context about the patch
- Provide a description of the history of changes in a
repository
- Cannot be modified once merged
- Format:
- Summary Line
- Body
- External References
- Guidelines: https://wiki.openstack.org/wiki/GitCommitMessages
Summary Line
=============
- Succinctly describes patch content
- Limited to 50 characters
- Should not end with a period
Exercise
========
Exercise 1
==========
Write a summary line for each of the following scenarios:
@ -46,20 +23,8 @@ Write a summary line for each of the following scenarios:
Share your favorite to our IRC channel.
Body
====
- Lines limited to 72 characters
- Explanation of issue being solved and why it should be fixed
- Explain how the problem is solved
- Other possible content
- Does it improve code structure?
- Does it fix limitations of the current code?
- References to other relevant patches?
Exercise
========
Exercise 2
==========
Write a commit message body to expand on each of the following summary
lines. Feel free to make up details to make the context more realistic.
@ -69,41 +34,9 @@ Share your favorite in IRC.
- Minimize database queries
- Added unit tests to cover untested methods
Do not assume ...
=================
- The reviewer understands what the original problem was
- The reviewer has access to external web services/site
- The code is self-evident/self-documenting
External References
===================
- Required:
- Change-Id
- Task Tracking Info:
- Bug (Partial-Bug, Related-Bug, Closes-Bug)
- Blueprint (Partial-Implements, Implements)
- Additional External References:
- DocImpact
- APIImpact
- SecurityImpact
- UpgradeImpact
- Depends-On
.. note::
Explain the tags and when you use them. Documentation, API,
Security or Upgrade Impacts are for patches with changes that
alter the existing state. Depends-On is for cross repository
dependencies. Change-Id's are filled in automatically with git
review -s.
Exercise
========
Exercise 3
==========
Write a commit message for the bug you created during our earlier
exercise. Include a summary line, body, and the required exernal references

162
doc/upstream-training/source/slides/workflow-project-status-and-zuul.rst
View File

@ -9,63 +9,8 @@ OpenStack Project Status and Zuul
.. note::
Tags: [new_dev] [dev]
OpenStack Infrastructure and Project Status
===========================================
- `http://status.openstack.org <http://status.openstack.org>`_
- Zuul
- Rechecks
- Reviews
- Bugday
- OpenStack-Health
.. note::
- Zuul is the project gating and automation system that tests and merges
changes as well as publishing releases and documentation.
- Rechecks has a list of bugs and associated information for
nondeterministic check/gate failures.
- Reviews has a list of important reviews based on blueprint and bug priority
organized by project.
- Bugday shows real-time stats during bug smash days.
- OpenStack-Health has a dashboard of overal OpenStack test results.
Zuul
====
.. image:: ./_assets/workflow-project-status-and-zuul-zuul-page.png
Zuul Pipelines
==============
- Check
- Run against all newly updated patch sets
- Runs unit testing, Pep8, docs/releasenote build and
functional tempest testing
- Zuul votes +1/-1 depending on test results
- Gate
- Only run after a patch is approved by a core reviewer
- More extensive testing than check pipeline
- Runs another unit test run along with additional tempest testing
- 'Gates' code entering the stable or master branches
Zuul Pipelines - cont.
======================
- Post
- Jobs run against a patch after it merges
- Documentation build/publishing, tarball generation, image build
.. note::
- The above jobs are examples of what is run in each pipeline.
What is actually run varies based upon the project being tested.
Exercise
========
Exercise 1
==========
- Look at the `Zuul <http://status.openstack.org/zuul>`_ status page
- Find the information that can be retrieved for each patch in a pipeline
@ -78,108 +23,9 @@ Exercise
- Discuss your findings with your group
Patch Number
============
.. image:: ./_assets/workflow-project-status-and-zuul-patch-id.png
:class: image-pad-top
.. note::
- The number next to 'Change' is the patch number.
- Can use the patch number to track status in Zuul status page.
Filtering on Patch Number in Zuul
=================================
.. image:: ./_assets/workflow-project-status-and-zuul-zuul-job-status.png
:class: image-pad-top
.. note::
- Shows the Zuul status page filtered down to just the patch of interest.
Zuul Failures
=============
.. image:: ./_assets/workflow-project-status-and-zuul-zuul-fail.png
:class: image-pad-top
Analysing Zuul Failures
=======================
- Logs may be accessed by clicking on the test's name
- Directs the user to saved log output
- Uses the browser to view the logs
- Voting and non-voting jobs
- Voting job failures cause a -1 vote from Zuul on the patch
- Non-voting jobs do not cause a -1 vote from Zuul upon failure
- Non-voting jobs are new jobs that are being tested and may not yet be ready
to vote
Logs
====
.. image:: ./_assets/workflow-project-status-and-zuul-zuul-failure-log-list.png
:class: image-pad-top
.. note::
- Example of what the logs for a run look like
- Actual log files will vary depending on the test you are examining
Logs - Testr HTML Report
========================
.. image:: ./_assets/workflow-project-status-and-zuul-failure-testr-html.png
:class: image-pad-top
Logs - Job Run Output
=====================
.. image:: ./_assets/workflow-project-status-and-zuul-failure-log.png
:class: image-pad-top
Intermittent Failures
=====================
- Caused by timing/connectivity issues in check/gate
- May receive elastic recheck message
- List of `Rechecks <http://status.openstack.org/elastic-recheck>`_
- To trigger a re-run of check or gate add a comment to the patch
in the form of 'recheck bug XXXXX'
Recheck Example
===============
.. image:: ./_assets/workflow-project-status-and-zuul-recheck-example.png
:class: image-pad-top
.. note::
- Note ability to see logstash and link to launchpad
What Are Rechecks
=================
- Issues causing intermittent failures
- Elastic search is used to look for logs indicating similar failures
- Users add new bugs to
`elastic-recheck <https://docs.openstack.org/infra/elastic-recheck/readme.html>`_
- Goal is to capture all instances of a failure in the hopes of identifying
patterns causing the bug
- Comments on patches that hit a known bug
Exercise
========
Exercise 2
==========
- Find how rechecks are categorized
- Discuss with your table how you would determine you encountered
one of these bugs