Merge remote-tracking branch 'pulp/master' into HEAD

AUTHORS

@@ -13,6 +13,7 @@ Jeremy Cline (jcline@redhat.com)
 Jason L Connor (jconnor@redhat.com)
 Barnaby Court (bcourt@redhat.com)
 Patrick Creech (pcreech@redhat.com)
+David Davis (daviddavis@redhat.com)
 Michael DeHaan (mdehaan@redhat.com)
 Jay Dobies (jason.dobies@redhat.com)
 Filip Dobrovolny (fdobrovo@redhat.com)
@@ -26,10 +27,12 @@ Eric D. Helms (ehelms@redhat.com)
 Michael Hrivnak (mhrivnak@redhat.com)
 Sayli Karmarkar (skarmark@redhat.com)
 Pradeep Kilambi (pkilambi@redhat.com)
+Jan-Otto Kröpke (mail@jkroepke.de)
 Austin Macdonald (amacdona@redhat.com)
 Og B. Maciel (ogmaciel@gnome.org)
 John Matthews (jmatthews@redhat.com)
 Mike McCune (mmccune@redhat.com)
+Sean Myers (sean.myers@redhat.com)
 Esly Nunez (ennunezc@gmail.com)
 Jeff Ortel (jortel@redhat.com)
 Ina Panova (ipanova@redhat.com)
@@ -40,9 +43,9 @@ Todd Sanders (tsanders@redhat.com)
 Justin Sherrill (jsherril@redhat.com)
 James Slagle (jslagle@redhat.com)
 Chris St. Pierre (chris.a.st.pierre@gmail.com)
+Tatiana Tereshchenko (ttereshc@redhat.com)
 Dmitry Vasilets (pronix.service@gmail.com)
 Florian Weimer (fw@deneb.enyo.de)
 Adam Young (ayoung@redhat.com)
 Lukas Zapletal (lzap+git@redhat.com)
 Bihan Zhang (bizhang@redhat.com)
-Jan-Otto Kröpke (mail@jkroepke.de)

bindings/setup.py

@@ -13,7 +13,7 @@
 
 setup(
     name='pulp-bindings',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test']),
     author='Pulp Team',

client_admin/setup.py

@@ -4,7 +4,7 @@
 
 setup(
     name='pulp-client-admin',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test']),
     author='Pulp Team',

client_consumer/setup.py

@@ -2,7 +2,7 @@
 
 setup(
     name='pulp-client-consumer',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test']),
     author='Pulp Team',

client_lib/setup.py

@@ -13,7 +13,7 @@
 
 setup(
     name='pulp-client-lib',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test']),
     author='Pulp Team',

common/setup.py

@@ -2,7 +2,7 @@
 
 setup(
     name='pulp-common',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test']),
     author='Pulp Team',

devel/setup.py

@@ -11,7 +11,7 @@
 
 setup(
     name='pulp-devel',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test', 'test.*']),
     author='Pulp Team',

oid_validation/setup.py

@@ -5,7 +5,7 @@
 
 setup(
     name='pulp-oid_validation',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test']),
     author='Pulp Team',

old_docs/dev-guide/contributing/branching.rst

@@ -111,9 +111,42 @@ branch that will need to contain your work.
 Commit Messages
 ---------------
 
-The primary commit in a bug fix should have a log message that starts with
-'<bug_id> - ', for example ``123456 - fixes a silly bug``.
+Commit messages in Pulp should contain a human readable explanation of what
+was fixed in the commit. They should also follow the standard git message
+format of starting with a subject line or title (usually wrapped at about 50
+chars) and optionally, a longer message (usually wrapped at 72 characters)
+broken up into paragraphs. For more on what constitutes a good commit message,
+we recommend `Tim Pope's blog post on the subject
+<http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>`_.
 
+It's also recommended that every commit message in Pulp reference an issue in
+`Pulp's Redmine issue tracker <https://pulp.plan.io>`_. To do this you should
+use both a keyword and a link to the issue.
+
+To reference the issue (but not change its state), use ``re`` or ``ref``::
+
+    re #123
+    ref #123
+
+To update the issue's state to MODIFIED and set the %done to 100, use
+``fixes`` or ``closes``::
+
+    fixes #123
+    closes #123
+
+You can also reference multiple issues in a commit::
+
+    fixes #123, #124
+
+Putting this altogether, the following is an example of a good commit message::
+
+    Update node install and quickstart
+
+    The nodes install and quickstart was leaving out an important step on
+    the child node to configure the server.conf on the child node.
+
+    closes #1392
+    https://pulp.plan.io/issues/1392
 
 Cherry-picking and Rebasing
 ---------------------------

old_docs/dev-guide/contributing/bugs.rst

@@ -46,6 +46,17 @@ 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:
 
 Security Disclosures
@@ -78,23 +89,25 @@ Developer
    state to ``ASSIGNED``.
 #. The developer creates a new remote branch for the bug on their GitHub fork.
 #. When the fix is complete, the developer submits a pull request for the bug into the appropriate
-   branch (master, release branch, etc.). It's appreciated by the reviewer if a link to the bug
-   is 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.
+   branch (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.
 #. When the pull request is submitted, the developer changes the status of the bug to ``POST`` and
-   sets the appropriate target release.
-#. Wait for someone to review the pull request. The reviewer will assign the pull request back to
-   the developer when done and should also ping them through other means. The developer may take
-   the reviewer's comments as they see fit and merge the pull request when satisfied. Once merged,
-   set bug status to ``MODIFIED``. It is also helpful to include a link to the pull request in a
-   comment on the bug.
+   includes a link to the open pull request.
+#. 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.
 #. Delete both local and remote branches for the bug.
 
 .. note::
   See :doc:`branching` for more information on how to create branches for bug fixes.
 
 Reviewer
 ^^^^^^^^
+
 #. 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.
@@ -149,8 +162,8 @@ Priorities are defined as follows.
 ========    ===============================================================================
 Priority    Description
 ========    ===============================================================================
-Urgent      Extremely important, such as issues that must be fixed before the next release.
-High        Very important, but not blocking the next release.
+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.
 ========    ===============================================================================

old_docs/dev-guide/contributing/building.rst

@@ -286,15 +286,26 @@ fedorapeople::
 Reconcile Redmine Issues
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Before starting a release build, ensure that there are no issues in a ``MODIFIED`` state without
-a Target Platform Release (See the "``MODIFIED`` - No Release" report in Redmine). All ``MODIFIED``
-issues should include a link to the pull request for the related bugfix or feature, and the
-target release can usually be determined by examining the destination branch of the pull
-request. If in doubt, consult with the developer that fixed the issue to know which target
+Before starting a release build, ensure that there are no issues
+blocking the version of Pulp about to be released by checking the
+`Open Blockers <https://pulp.plan.io/projects/pulp/issues?query_id=75>`_ report in Redmine.
+
+If a release is not blocked, make sure that any issues in a ``MODIFIED`` state that apply
+to the branch being released have the Platform Release field set correctly. See the
+`MODIFIED - No Release <https://pulp.plan.io/projects/pulp/issues?query_id=65>`_ report in Redmine
+for a list of issues that are ``MODIFIED`` but not value for the Platform Release field.
+
+All ``MODIFIED`` issues should include a link to the pull request for the related bugfix or feature.
+The target release can be determined by examining the destination branch of the pull request:
+
+* Changes made on an ``x.y-dev`` branch belong in the next bugfix (Z) release.
+* Changes made on master go into the next feature (Y) release.
+
+If in doubt, check with the developer that fixed the issue to determine which target
 release is appropriate.
 
 Similarly, if there are any issues that are ``NEW``, ``ASSIGNED``, or ``POST`` and inappropriately given
-a Target Platform Release, set the Target Platform Release field to none on those issues.
+a Platform Release, set the Platform Release field to none on those issues.
 
 Submit to Koji
 ^^^^^^^^^^^^^^

old_docs/dev-guide/contributing/merging.rst

@@ -155,6 +155,5 @@ strategy "ours".
 
 In either case, git's history records that your fix has been applied to each
 branch. Make sure the human-readable description of your fix accurately
-describes its scope. For example, a good commit message would be "Fixed memory
-use issue in ABC system, which was removed in pulp 2.8", or "Fixed a python 2.4
-compatibility issue that is no longer applicable as of pulp 2.8".
+describes its scope. For more on how to write a good commit message, see the
+Commit Messages section of our `branching page </dev-guide/branching>`_.

old_docs/user-guide/release-notes/2.10.x.rst

@@ -2,6 +2,27 @@
 Pulp 2.10 Release Notes
 =======================
 
+Pulp 2.10.2
+===========
+
+* This is a hotfix release.
+
+Known Issues
+------------
+
+* Upgrading on EL 7.3 can take longer than on other platforms. `pulp-selinux` package unnecessarily
+  runs restorecon on `/var/lib/pulp`. The duration of upgrade depends on the amount of content in
+  that directory.
+* As part of fixing the above issue, it was also discovered that upgrading from 2.10.0 can take
+  longer than from 2.9.1 and earlier versions. The fix for this `issue
+  <https://pulp.plan.io/issues/2424>`_ will be released with 2.10.3.
+
+Bug Fixes
+---------
+
+See the list of :fixedbugs:`2.10.2`
+
+
 Pulp 2.10.1
 ===========
 

old_docs/user-guide/troubleshooting.rst

@@ -26,6 +26,11 @@ CRITICAL, ERROR, WARNING, INFO, DEBUG, and NOTSET.
    rsyslog typically only displays INFO and higher, so if you set Pulp to DEBUG it will still be
    filtered by rsyslog. See the :ref:`rsyslogd` section for more information.
 
+.. note::
+
+   Pulp reads the log level configuration during startup. If the log level is changed while Pulp is
+   running, then you will need to restart it.
+
 journald
 ^^^^^^^^
 

repoauth/setup.py

@@ -3,7 +3,7 @@
 
 setup(
     name='pulp-repoauth',
-    version='2.11a1',
+    version='2.12a1',
     license='GPLv2+',
     packages=find_packages(exclude=['test']),
     author='Pulp Team',

server/pulp/plugins/util/publish_step.py

@@ -901,7 +901,11 @@ def process_main(self, item=None):
 
         try:
             os.rename(self.source_dir, timestamp_master_dir)
-            selinux.restorecon(timestamp_master_dir.encode('utf-8'), recursive=True)
+            try:
+                selinux.restorecon(timestamp_master_dir.encode('utf-8'), recursive=True)
+            except OSError as e:
+                if e.errno != errno.EPERM:
+                    raise
         except OSError as e:
             if e.errno == errno.EXDEV:
                 copytree(self.source_dir, timestamp_master_dir, symlinks=True)

server/pulp/plugins/util/verification.py

@@ -14,6 +14,9 @@ class VerificationException(ValueError):
 
 def verify_size(file_object, expected_size):
     """
+    Depricated. Do not use it anymore. Use os.stat to find out the file size to compare
+    with the expected one.
+
     Returns whether or not the size of the contents of the given file-like object match
     the expectation.
 

server/pulp/server/content/storage.py

@@ -1,6 +1,7 @@
 import os
 import errno
 import shutil
+import tempfile
 
 from hashlib import sha256
 
@@ -107,7 +108,10 @@ def get_path(unit):
     def put(self, unit, path, location=None):
         """
         Put the content defined by the content unit into storage.
-        The file at the specified *path* is transferred into storage.
+        The file at the specified *path* is transferred into storage:
+         - Copy file to the temporary file at its final directory.
+         - If possible, verify size of the file to make sure that file is not corrupted.
+         - Do atomic rename.
 
         :param unit: The content unit to be stored.
         :type unit: pulp.sever.db.model.ContentUnit
@@ -121,7 +125,24 @@ def put(self, unit, path, location=None):
         if location:
             destination = os.path.join(destination, location.lstrip('/'))
         mkdir(os.path.dirname(destination))
-        shutil.copy(path, destination)
+        fd, temp_destination = tempfile.mkstemp(dir=os.path.dirname(destination))
+
+        # to avoid a file descriptor leak, close the one opened by tempfile.mkstemp which we are not
+        # going to use.
+        os.close(fd)
+
+        shutil.copy(path, temp_destination)
+
+        try:
+            unit.verify_size(temp_destination)
+        except AttributeError:
+            # verify_size method is not implemented for the unit
+            pass
+        except:
+            os.remove(temp_destination)
+            raise
+
+        os.rename(temp_destination, destination)
 
     def get(self, unit):
         """

server/pulp/server/controllers/importer.py

@@ -254,7 +254,7 @@ def update_importer_config(repo_id, importer_config):
     # repo_importer.config needs to be changed
     for k, v in importer_config.iteritems():
         if v is None:
-            repo_importer.config.pop(k)
+            repo_importer.config.pop(k, None)
         else:
             repo_importer.config[k] = v