Description of problem: The beaker-expire-distros cron job in my devel environment fired shortly after the machine was powered on (after a full shutdown for a power outage). It got this exception from the local beaker-proxy at 2013-06-24 10:01:02 +10:00: Traceback (most recent call last): File "/usr/bin/beaker-expire-distros", line 9, in <module> load_entry_point('bkr.labcontroller==0.13.0', 'console_scripts', 'beaker-expire-distros')() File "/usr/lib/python2.6/site-packages/bkr/labcontroller/expire_distros.py", line 105, in main check_all_trees(options.ignore_errors) File "/usr/lib/python2.6/site-packages/bkr/labcontroller/expire_distros.py", line 66, in check_all_trees distro_trees = proxy.get_distro_trees() File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request return self._parse_response(h.getfile(), sock) File "/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response return u.close() File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: <Fault 1: "<class 'turbogears.identity.exceptions.IdentityFailure'>: Not member of group: lab_controller"> I saw this in beaker-proxy.log: 2013-06-24 10:01:01 [DEBUG ] { 1711} bkr.labcontroller.main:37 Time: 0:00:00.517346 get_distro_trees () 2013-06-24 10:03:26 [INFO ] { 1711} kobo.client.HubProxy:207 Creating new session... 2013-06-24 10:03:29 [INFO ] { 1711} kobo.client.HubProxy:225 New session created. So it seems like beaker-proxy pid 1711 had started and was servicing requests a full two minutes before it attempted (or succeeded?) to authenticate to the Beaker server. I'm using Kerberos authentication in this environment. Version-Release number of selected component (if applicable): beaker-lab-controller-0.13.0-3.el6eng.noarch How reproducible: unsure Steps to Reproduce: not known, but my guess is: 1. reboot the lab controller 2. somehow try to ensure beaker-expire-distros runs immediately after bootup
Solution to this might be to modify systemd configuration of beaker-proxy so we wait until network is fully up?
Closing this issue. We are not planning to address this problem in the Beaker development lifecycle. Instead of that, we are planning to continue our effort in building Beaker.NEXT. If you have any questions, feel free to reach out to me. Best regards, Martin Styk