AgeCommit message (Collapse)AuthorFilesLines
2018-04-11Automatic commit of release 25.1beaker-25.1Róman Joost7-8/+8
Change-Id: I625a648fec293fc4e502de8776497ffc40e24498
2018-04-10tests: always run mail capturing threadDan Callaghan9-130/+184
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/", line 28, in send_mail turbomail.send(message) File "/usr/lib/python2.7/site-packages/turbomail/", line 18, in send return interface.send(message) File "/usr/lib/python2.7/site-packages/turbomail/", line 153, in send return self.manager.deliver(message) File "/usr/lib/python2.7/site-packages/turbomail/managers/", line 53, in deliver self.transport.deliver(message) File "/usr/lib/python2.7/site-packages/turbomail/transports/", line 137, in deliver self.connect_to_server_if_nessary() File "/usr/lib/python2.7/site-packages/turbomail/transports/", line 97, in connect_to_server_if_nessary self.connection = self.connect_to_server() File "/usr/lib/python2.7/site-packages/turbomail/transports/", line 87, in connect_to_server connection.connect(self.server) File "/usr/lib64/python2.7/", line 315, in connect self.sock = self._get_socket(host, port, self.timeout) File "/usr/lib64/python2.7/", line 290, in _get_socket return socket.create_connection((host, port), timeout) File "/usr/lib64/python2.7/", 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
2018-04-09Beaker 25.1 release notesRóman Joost1-0/+32
Change-Id: I3abb9220d19c72953298b4ee4ce0c4f27ea05eb9
2018-04-09Lookup iPXE compatible URLs to generate scriptRóman Joost4-3/+94
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
2018-04-06Remove release notes for workflow-reserve commandRóman Joost1-7/+0
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
2018-04-06bkr workflow-reserve: reserve a systemMatt Tyson1-8/+8
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
2018-04-06bkr workflow-reserve: reserve a systemMatt Tyson4-0/+257
Bug: 1165960 Change-Id: I0826647a69ee705094f0cc0d10b64b22169b0786
2018-04-06Adjust installation failure detection patternRóman Joost4-2/+349
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
2018-03-28fix "not enough systems" logicDan Callaghan3-0/+34
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 were visible to the later queries. Now that these steps all happen inside a single transaction, we need to explicitly flush changes to before any queries use recipe.dyn_systems. Bug: 1558828 Change-Id: I671683a69e6a696be7d0c453c967406a95446fd7
2018-03-27tests: reduce number of queries from data_setup.create_distro_tree()Dan Callaghan16-116/+141
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
2018-03-27update scheduler_status in reserve/unreserve methods instead of allocate/releaseDan Callaghan3-3/+33
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
2018-03-27extra debug logging for scheduler_status changesDan Callaghan2-0/+10
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
2018-03-23Allow to remove the keystone trust in BeakerRóman Joost3-3/+37
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