extras-buildsys ChangeLog,1.25,1.26

[Daniel Williams (dcbw)]

Author: dcbw

Update of /cvs/fedora/extras-buildsys
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv3560

Modified Files:
	ChangeLog 
Log Message:
2005-06-24  Dan Williams <dcbw at redhat.com>

    * server/Repo.py
        - Deal with repo locking during createrepo stages

    * Ensure repositories can run createrepo without being accessed
        by clients during the operation.  Since createrepo runs can take
        a long time, during that time clients cannot try to install their
        buildroots or do any operations against the repository, otherwise
        they may fail randomly with yum errors.  So we lock access to the
        repository on a 2-level lock: when a build job is done, it asks the
        repo to copy its finished RPMs, and the repo enters lock level 1.
        Level 1 prevents new build jobs from entering their 'prep' state.
        When all currently running jobs have finished their prep state, and
        the repo is in lock level 1, the repo promotes to lock leve 2 and
        is able to run createrepo after copying any new RPMs into the repo.
        When this is done, all waiting clients are released into their
        'prep' states.

        This requires an absolute latest mock from CVS.




Index: ChangeLog
===================================================================
RCS file: /cvs/fedora/extras-buildsys/ChangeLog,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- ChangeLog	24 Jun 2005 10:55:14 -0000	1.25
+++ ChangeLog	24 Jun 2005 12:51:21 -0000	1.26
@@ -1,5 +1,26 @@
 2005-06-24  Dan Williams <dcbw at redhat.com>
 
+    * server/Repo.py
+        - Deal with repo locking during createrepo stages
+
+    * Ensure repositories can run createrepo without being accessed
+        by clients during the operation.  Since createrepo runs can take
+        a long time, during that time clients cannot try to install their
+        buildroots or do any operations against the repository, otherwise
+        they may fail randomly with yum errors.  So we lock access to the
+        repository on a 2-level lock: when a build job is done, it asks the
+        repo to copy its finished RPMs, and the repo enters lock level 1.
+        Level 1 prevents new build jobs from entering their 'prep' state.
+        When all currently running jobs have finished their prep state, and
+        the repo is in lock level 1, the repo promotes to lock leve 2 and
+        is able to run createrepo after copying any new RPMs into the repo.
+        When this is done, all waiting clients are released into their
+        'prep' states.
+
+        This requires an absolute latest mock from CVS.
+
+2005-06-24  Dan Williams <dcbw at redhat.com>
+
     * server/BuildMaster.py
       server/client_manager.py
         - Trap more errors