commit 0872cc24e83bbb93de082451dfd831f9f35d08f1 Author: Róman Joost Date: Wed Apr 11 09:41:52 2018 +1000 Automatic commit of release 25.1 Change-Id: I625a648fec293fc4e502de8776497ffc40e24498 commit 9212af3c7512389e5636f6d401a74c3c2b15fef0 Author: Dan Callaghan Date: Mon Mar 26 21:30:46 2018 +1000 tests: always run mail capturing thread This avoids the harmless but scary-looking error spew from the tests whenever they use data_setup to mark a job as completed (which sends a mail), like this: 2018-03-21 19:41:26,972 bkr.server.mail ERROR Exception thrown when trying to send mail Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/bkr/server/mail.py", line 28, in send_mail turbomail.send(message) File "/usr/lib/python2.7/site-packages/turbomail/__init__.py", line 18, in send return interface.send(message) File "/usr/lib/python2.7/site-packages/turbomail/control.py", line 153, in send return self.manager.deliver(message) File "/usr/lib/python2.7/site-packages/turbomail/managers/immediate.py", line 53, in deliver self.transport.deliver(message) File "/usr/lib/python2.7/site-packages/turbomail/transports/smtp.py", line 137, in deliver self.connect_to_server_if_nessary() File "/usr/lib/python2.7/site-packages/turbomail/transports/smtp.py", line 97, in connect_to_server_if_nessary self.connection = self.connect_to_server() File "/usr/lib/python2.7/site-packages/turbomail/transports/smtp.py", line 87, in connect_to_server connection.connect(self.server) File "/usr/lib64/python2.7/smtplib.py", line 315, in connect self.sock = self._get_socket(host, port, self.timeout) File "/usr/lib64/python2.7/smtplib.py", line 290, in _get_socket return socket.create_connection((host, port), timeout) File "/usr/lib64/python2.7/socket.py", line 571, in create_connection raise err error: [Errno 111] Connection refused The mails will now be delivered and silently discarded if the test case does not want to capture them. Change-Id: Ic7dac7d7943046fe94f6fde05183e5a74ea1cab2 commit 5c35ddca3de45bc407ca8f9a6685d286ed3e238b Author: Róman Joost Date: Mon Apr 9 15:00:33 2018 +1000 Beaker 25.1 release notes Change-Id: I3abb9220d19c72953298b4ee4ce0c4f27ea05eb9 commit 6f0b61368f8e22da90b7d9a39f1b297318df51b7 Author: Róman Joost Date: Wed Apr 4 15:27:42 2018 +1000 Lookup iPXE compatible URLs to generate script The ipxe-script end point relies on generating the script with HTTP/FTP URLs for iPXE to boot from. If the primary URL is an NFS URL the joining of NFS urls with the kernel and initrd paths will result in relative paths instead of URLs. This partially puts in code which the end point used to lookup HTTP/FTP URLs from the lab controller in order for iPXE to work. Bug: 1563072 Change-Id: I0d94665f27d1da0b91380e0ade29b33f789f4103 commit 47e53f9c59d4af2d5114823fc7203da72753bb08 Author: Róman Joost Date: Wed Mar 28 17:17:34 2018 +1000 Remove release notes for workflow-reserve command This going into a bug fix there is no need anymore to include this in the release notes for the next major release. Change-Id: I6cccafa10708ee0c6da8dd4d137de5f9c2655aa7 commit b817b3f092bae6c3831674ae1b0b8b35472c0459 Author: Matt Tyson Date: Tue Mar 13 07:10:25 2018 -0400 bkr workflow-reserve: reserve a system Fix broken doc markup. Options such as --machine, --arch, --distro are options that belong to the bkr client itself. The proper cross referencing needs to be set up so Sphinx can generate links back to the bkr client docs, instead of looking for the options in the current doc. Change-Id: I702d4fc3b8d06d7dc54df9c731fec58f4dfee6c3 commit 33c577b567b48f28e4af0f1e3d156cc07a373fe3 Author: Matt Tyson Date: Tue Feb 20 23:04:55 2018 -0500 bkr workflow-reserve: reserve a system Bug: 1165960 Change-Id: I0826647a69ee705094f0cc0d10b64b22169b0786 commit 4cd8c50774ece1e31490decb20ae1149c6032a71 Author: Róman Joost Date: Wed Apr 4 16:18:21 2018 +1000 Adjust installation failure detection pattern The wording in anaconda has changed slightly to expect user input if the installation has failed. The Enter key is spelled uppercase in recent versions and the sentence ends with a colon. This patch changes the pattern slightly to accommodate the change. Bug: 1552401 Change-Id: I4a51bb9af89facb92848f4f3ad951a3e1a834000 commit 5a52379713287f142fd577a51172af85188c90cc Author: Dan Callaghan Date: Tue Mar 27 13:17:55 2018 +1000 fix "not enough systems" logic This regressed when it was refactored in commit a713fd08. Previously, the "not enough systems" logic was in a separate beakerd loop to the system allocation code (process_queued_recipe vs. schedule_processed_recipe) which means there was an intervening session flush and close between them, so that the changes to recipe.systems were visible to the later queries. Now that these steps all happen inside a single transaction, we need to explicitly flush changes to recipe.systems before any queries use recipe.dyn_systems. Bug: 1558828 Change-Id: I671683a69e6a696be7d0c453c967406a95446fd7 commit 4b959ffd6fd249bac38545f6a675633e1262b685 Author: Dan Callaghan Date: Mon Mar 26 17:31:20 2018 +1000 tests: reduce number of queries from data_setup.create_distro_tree() Avoid lazy_create in favour of direction objection creation. Also insert into distro_tree_lab_controller_map directly, instead of through the ORM, to avoid firing the mark_systems_pending_when_distro_tree_added_to_lab event listener. That listening can trigger a very large number of queries if there are many lab controllers and systems already in the database. Change-Id: I04db00aee61e05f809d9ebb5954668e85529230f commit 4added5df72990d33f2de5420da3d7ab9bb31496 Author: Dan Callaghan Date: Wed Mar 21 17:02:48 2018 +1000 update scheduler_status in reserve/unreserve methods instead of allocate/release Previously, the SystemResource.allocate() and SystemResource.release() methods were responsible for updating the System.scheduler_status attribute, to indicate to whether the scheduler should look at the system for scheduling. However the SystemResource.release() method had the statement in the wrong place. That method is called on *every* resource in *every* recipe in a job, even if the resource has already been released. That means the scheduler_status attribute was being incorrectly set to Pending in cases where the resource had already been released before. The statement should have gone after the short-circuit condition at the top of that method. This patch adds a comment on top of all the resource .release() methods to point out this very non-obvious convention. There is already a comment to this effect in Recipe.cleanup() but you don't see that when modifying the .release() methods. And this patch also moves the responsibility for updating scheduler_status into the System.reserve() and System.unreserve() methods, which seems like a cleaner place anyway. Those methods are only called when a change is actually being made, which is what we want. Bug: 1558776 Change-Id: Ic88a6a343d2fcca8e6e71a31dad444b28ea7518a commit 03002c8128b81e2a73db67a9cb11fdec5010b247 Author: Dan Callaghan Date: Wed Mar 21 15:54:18 2018 +1000 extra debug logging for scheduler_status changes Added this while debugging bug 1558776, although the problem turned out to be elsewhere. But the log messages nevertheless seem like they would be helpful. Change-Id: Idf5db62736ba701a218733a7b70086fe64c01e05 commit ffe8dd6cc766693c9f54a854a7d23389363d58d1 Author: Róman Joost Date: Fri Mar 23 11:27:21 2018 +1000 Allow to remove the keystone trust in Beaker If a trust has been invalidated outside of Beaker (e.g. OpenStack deployment was upgraded), it is possible that the VirtManager can not be instantiated due to the session can not be established. In that instance ignore the fact that we can not delete the trust in OpenStack and just proceed with deleting it in Beaker. Otherwise the only way to remove the old trust is by creating a new trust. Bug: 1557847 Change-Id: I8d5ebc04ccbc4066aa0f0ab09cdd823bb67f2308