commit 0872cc24e83bbb93de082451dfd831f9f35d08f1
Author: Róman Joost <rjoost@redhat.com>
Date: Wed Apr 11 09:41:52 2018 +1000
Automatic commit of release 25.1
Change-Id: I625a648fec293fc4e502de8776497ffc40e24498
commit 9212af3c7512389e5636f6d401a74c3c2b15fef0
Author: Dan Callaghan <dcallagh@redhat.com>
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 <rjoost@redhat.com>
Date: Mon Apr 9 15:00:33 2018 +1000
Beaker 25.1 release notes
Change-Id: I3abb9220d19c72953298b4ee4ce0c4f27ea05eb9
commit 6f0b61368f8e22da90b7d9a39f1b297318df51b7
Author: Róman Joost <rjoost@redhat.com>
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 <rjoost@redhat.com>
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 <mtyson@redhat.com>
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 <mtyson@redhat.com>
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 <rjoost@redhat.com>
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 <dcallagh@redhat.com>
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 <dcallagh@redhat.com>
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 <dcallagh@redhat.com>
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 <dcallagh@redhat.com>
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 <rjoost@redhat.com>
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