[01:59] <mup> Bug #1764592 opened: Machines intermittently down, with node stuck in Allocated <juju:New> <MAAS:New> <https://launchpad.net/bugs/1764592>
[02:11] <mup> Bug #1764592 changed: Machines intermittently down, with node stuck in Allocated <juju:New> <MAAS:New> <https://launchpad.net/bugs/1764592>
[02:14] <mup> Bug #1764592 opened: Machines intermittently down, with node stuck in Allocated <juju:New> <MAAS:New> <https://launchpad.net/bugs/1764592>
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
[09:31] <cnf> morning
[14:04] <ananke> hmm, wonder if upgrade to 2.3.2 resulted in nodes failing to enlist. they boot from pxe just fine, load the initial ramdisk & rootfs, and proceed with boot. after they reach network stage they hang for a few minutes, and eventually they produce python stack trace about not being able to find the data source
[14:05] <ananke> sniffing traffic on that interface on the maas rackd controller shows no traffic at that point
[14:11] <ananke> hah, I wonder if this is the problem: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1665680
[14:19] <roaksoax> ananke: check that rackd.conf points to the right IP
[14:22] <ananke> roaksoax: it's pointing to a hostname, that should be resolvable. (just found that in another post). however, this led me to discover that there may be an issue with resolver setup on the nodes that are trying to enlist
[14:23] <ananke> seems there may have been residual problems/settings with the OS on this rack controller. it got booted/installed from one network, which is no longer present
[14:28] <ananke> hah, nope. I think I got it. wrong gateway settings. damn
[14:29] <ananke> no wonder I wasn't seeing any traffic
[14:31] <ananke> hah. that was it
[14:56] <roaksoax> hah :)
[15:46] <mup> Bug #1764784 opened: autocompletion in action panel popup has scrollbars <MAAS:New for ya-bo-ng> <https://launchpad.net/bugs/1764784>
[16:05] <ananke> roaksoax: yeah, completely forgot to redo that particular config option after I redeployed the rack controller
=== frankban is now known as frankban|afk
[17:55] <mup> Bug # changed: 1634595, 1704501, 1708609, 1730525, 1738127, 1742708, 1747459, 1749872, 1751300, 1751899, 1751901, 1751905, 1751908, 1753493, 1753496, 1755587, 1759284,
[17:55] <mup> 1759708, 1760037, 1760666, 1760668, 1760702, 1760919, 1760958, 1761120, 1761326, 1761584, 1761766, 1761768, 1763059, 1763214, 1763215, 1763216, 1763831
[18:49] <mup> Bug #1764830 opened: Images do not sync after a simplestreams No signature found error is reported in the regiond.log <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1764830>
[18:58] <mup> Bug #1764830 changed: Images do not sync after a simplestreams No signature found error is reported in the regiond.log <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1764830>
[19:04] <mup> Bug #1764830 opened: Images do not sync after a simplestreams No signature found error is reported in the regiond.log <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1764830>
[19:19] <mup> Bug #1764830 changed: Images do not sync after a simplestreams No signature found error is reported in the regiond.log <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1764830>
[19:40] <mup> Bug #1764830 opened: Images do not sync after a simplestreams No signature found error is reported in the regiond.log <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1764830>
[19:55] <mup> Bug #1764830 changed: Images do not sync after a simplestreams No signature found error is reported in the regiond.log <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1764830>
[20:07] <mup> Bug #1764830 opened: rack controller list-boot-images shows status 'unknown' <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1764830>