Bugs

All bugs are tracked in Redmine as an Issue. You can view existing bugs as examples.

How to file a bug

Bugs are one of the main ways that the Pulp team interacts with users (pulp-list@redhat.com and the #pulp IRC channel being the other methods).

You can file a new bug.

Warning

Is this security related? If so, please follow the Security Disclosures process.

If you are filing an issue or defect, select Issue as the Tracker. If you are filing a feature request, select Story.

Fill in the Subject and Description. Leave the status at NEW. Please select the closest corresponding Category, if any. Select the Severity field and any Tags based on your best judgement.

Use the Version field to indicate which Pulp version you are using. It has an entry for each Pulp release (2.0.6, 2.0.7, 2.1.0, etc.). If a bug is found when running from source instead of a released version, the value 2-master should be selected.

Use the OS field to indicate which Operating System the bug was discovered on.

You can also upload attachments, but please only upload relevant data. For example, if you have an entire log which contains some errors, please trim it to just the relevant portions and upload those.

Once a week, the Pulp team triages all new bugs, at which point its Severity rating and other aspects of the report will be evaluated. If necessary, the bug may be commented on requesting more information or clarification from the reporter. When a bug has enough information, its Priority rating set and is marked as triaged using the Triaged boolean.

Blocking Bugs

All Redmine Issues have a “Blocks Release” field. This field refers to upcoming Platform Release versions that cannot be released until this bug is fixed.

For example, if a blocking issues is discovered in Pulp 2.4.6, and 2.4.7 is the next Platform Release version, then the issue’s “Blocks Release” field should be set to 2.4.z. If the bug also affects the next Platform Release of Pulp, such as 2.5.2, the issue’s “Block Release” field should also include 2.5.z.

Security Disclosures

We take security issues seriously and welcome responsible disclosure of security vulnerabilities in Pulp. Please email pulp-security@redhat.com (a private address for the Pulp Security Team) with all reports.

Your report should include:

  • Pulp version

  • A vulnerability description

  • Reproduction steps

Feel free to submit a patch with your disclosure. A member of the Pulp Security Team will confirm the vulnerability, determine its impact, and develop a fix.

Fixing

When fixing a bug, all bugs will follow this process, regardless of how trivial.

First of all you need to reproduce this bug. If this error is connected with client try to use -vv flag to obtain complete information. It can also be useful to look into server log. If there is a traceback, try to look there first and individualy look for the bug. In some cases you can try to reproduce the error in the python console. Be aware of the fact that bug can not only be caused by just the plugin or just the platform, it could also be caused by the interaction of faults present in both components. Always fix any unittests broken by a change, and add new test code to cover code additions. Before you commit manualy test if bug is fixed after that you should run all unittests via run-tests.py to check whether something got broken by your fix. If tests pass you are good to push and submit PR by rules mentioned below.

Note

In systems that use systemd such as RHEL 7 (and later) and Fedora 15 (and later) you can use

journalctl -u goferd.service \
           -u httpd.service \
           -u pulp_workers.service \
           -u pulp_celerybeat.service \
           -u pulp_resource_manager.service \
           -u pulp_streamer.service

also you can add --boot switch to view logs only from the current boot of the system. On other systems take a look into /var/log/messages.

Developer

  1. Once the bug has been triaged it waits for a developer to pick it up. Generally developers should pick bugs from the top of the Prioritized Bugs query.

  2. Once a bug is selected, the developer sets themselves as the assignee and also sets the bug state to ASSIGNED.

  3. The developer creates a new remote branch for the bug on their GitHub fork.

  4. When the fix is complete, the developer submits a pull request for the bug into the appropriate branch (2-master, release branch, etc.). A link to the bug should be included in the merge request, as well as a brief description of what the change is. It is not required to find and assign someone to do the review.

  5. When the pull request is submitted, the developer changes the status of the bug to POST and includes a link to the open pull request. Pull requests with the Work In Progress label should remain in ASSIGNED state until the Work In Progress label is removed.

  6. Wait for someone to review the pull request. The reviewer(s) will either approve the pull request or request changes that must be addressed before the pull request can be merged. Pull requests should have at least one approved review and no reviews requesting changes before being merged. Once merged, set the bug status to MODIFIED. If the next platform release version is known, set the “Platform Release” field appropriately. Otherwise, leave it blank and it will be set during the next platform bugfix release.

  7. Delete both local and remote branches for the bug.

Note

See Branching Model for more information on how to create branches for bug fixes.

Reviewer

  1. When reviewing a pull request, all feedback is appreciated, including compliments, questions, and general Python knowledge. It is up to the developer to decide what (if any) changes will be made based on each comment.

  2. When done reviewing, assign the pull request back to the developer and ping them through other means.

Triage Process

Pulp holds bug triage as an IRC meeting on Tuesdays and Fridays at 10:30 ET (either EST or EDT) in #pulp-dev on Freenode. We encourage bug filers and interested parties to join and give input.

A quorum of at least 2 core developers (including the triage lead) is required to hold triage. Quorum must be established at the beginning of the meeting. Developers forming the quorum must stay for the entire duration of triage or the meeting must be suspended. Triage will be led by the “triage lead” which is a role that can be rotated each month. The triage lead is responsible for reaching out to other developers to ensure a quorum can be established.

The triage lead uses IRC bot to facilite the meeting. The available set of commands with description is provided (e.g. !start, !next, !propose, !accept, !end, etc).

The triage lead will do the following:

  1. Announce the meeting in #pulp-dev 10 minutes prior to beginning.

  2. Post the link to all Un-Triaged Bugs along with the announce of the meeting.

  3. Start the meeting when there is a quorum.

  4. For each issue to be triaged, facilitate an agreement on the priority and severity from anyone in the chat. In cases where there is not much feedback, at a minimum the triage lead needs an ack from the other quorum member before moving on. If agreement cannot be reached within several minutes, skip the bug and let interested parties post their thoughts on the bug.

  5. Update the issue as being triaged. Add any severity and priority changes, component/tag changes, and add any comments that come in from the chat. It’s preferred for comments to be left directly versus having the triage lead leave comments made by others.

If a bug needs to block a release, follow the blocking bugs process. The “Target Platform Release” field should never be set before the issue is in MODIFIED state.

If a bug is not publicly available (e.g. security issue), it should be skipped and revisited after triage by the core developers.

Bugs that need additional information will have notes put onto the issue asking for input. Unless a Redmine user specifically disabled e-mail support, adding a note will e-mail the reporter. Bugs with enough information and an agreed upon severity and priority, will be triaged. Also any components or tags should be set.

Once triaged, the bug is included in the Prioritized Bugs query and awaits a developer to pick it up.

Triage Issue Fields

The Priority field represents the order in which issues will be taken from the list of prioritized bugs, with higher priority issues generally being taken before lower priority issues.

Priorities are defined as follows.

Priority

Description

Urgent

Most important. Non-Urgent issues should not be worked on before this issue.

High

Very important, generally worked on after Urgent Priority issues.

Normal

Average importance, generally worked on after High Priority issues.

Low

Not very important, generally worked on after Normal Priorty issues.

The Severity field represents the impact this issue has on Pulp users.

Severity

Description

Urgent

Catastrophic issue which severly impacts the operations of an organization (including the Pulp team itself), for which there is no workaround. Examples: Pulp can’t be installed or started as a result of a bug in the latest release, or Pulp is destroying user data.

High

Similar to Urgent, this issue severly impacts to operations of an organization, but a workaround does exist. Examples: Pulp can only be installed if a certain package is manually installed first, or an existing feature of Pulp has suffered a regression.

Medium

Partial but non-critical functionality loss, or other loss of functionality where users are still able to perform their critical tasks.

Low

Little or no functionality impact, such as a usage question, or development work.

Severity is orthogonally related to the Priority field, so it is possible (though extremely unlikely) for an Urgent Priority issue to also be marked as Low Severity.

The values for the Priority and Severity fields are inspired by the values found in Red Hat’s Bugzilla Field Descriptions.

The Pulp team uses some additional Tags to help keep track of bugs.

Tag Name

Usage

Documentation

The bug/story itself is documentation related.

EasyFix

A bug that is simple to fix, at least in theory.

SELinux

Indicates it is SELinux related

Grooming

You may occasionally see discussion in #pulp or on the mailing list about “bug grooming”. This simply means that someone is applying the rules above to existing bugs that are not new. This is needed from time to time to keep the bug list up to date.