|Age||Commit message (Collapse)||Author||Files||Lines|
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
File "/usr/lib/python2.7/site-packages/turbomail/__init__.py", line 18, in send
File "/usr/lib/python2.7/site-packages/turbomail/control.py", line 153, in send
File "/usr/lib/python2.7/site-packages/turbomail/managers/immediate.py", line 53, in deliver
File "/usr/lib/python2.7/site-packages/turbomail/transports/smtp.py", line 137, in deliver
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
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
error: [Errno 111] Connection refused
The mails will now be delivered and silently discarded if the test case
does not want to capture them.
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.
This going into a bug fix there is no need anymore to include this in
the release notes for the next major release.
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.
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.
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
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.
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
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.
Added this while debugging bug 1558776, although the problem turned out
to be elsewhere. But the log messages nevertheless seem like they would
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.