[00:21] <wililupy> I found an entry in /usr/lib/python2.7/dist-packages/maasserver/modes/node.py defining commissioning time for 20 minutes, but when I modify it to 40, it still only runs for 20. Am I going in the right direction here?
[00:22] <wililupy> sorry, /usr/lib/python2.7/dist-packages/maasserver/models/node.py
[01:28] <wililupy> Actually, it might have taken the changes this time. Its been commissioning now for 30 minutes and hasn't timed out yet. I restarted the server after making the change this time and it seems like it is working.
[01:34] <wililupy> Sweet! Changing the value in the node.py file adjusted the timeout. The servers are now commissioning properly and going into the Ready state!
[12:13] <mup> Bug #1531836 opened: Power state does not show on node using Digital Loggers PDU <power> <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1531836>
[12:16] <mup> Bug #1531836 changed: Power state does not show on node using Digital Loggers PDU <power> <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1531836>
[12:31] <mup> Bug #1531836 opened: Power state does not show on node using Digital Loggers PDU <power> <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1531836>
[12:41] <mup> Bug #1531843 opened: [Xenial 1.10] IPMI query fails <1.10> <ipmi> <xenial> <MAAS:New> <https://launchpad.net/bugs/1531843>
[13:23] <jam> I frequently have trouble enlisting nodes, where it gives me "failed to enlist system maas server 'm2-test1.maas....'
[13:24] <jam> where the name there matches the last node that I successfully enlisted.
[13:24] <jam> has anyone seen that?
[13:24] <jam> AFAICT, it looks like something where when a node boots, it gets an IP address (in this case 200*) which then successfully enlists
[13:24] <jam> so it gets a DNS address.
[13:24] <jam> but once that node is successfully in rotation, it gets a different address.
[13:25] <jam> and then the next node that tries to enlist, gets the same Dynamic DHCP address (which is perfectly fine)
[13:25] <jam> but DNS still thinks it is the same node
[13:25] <jam> and it fails
[14:12] <jam> dimitern: I can confirm that without your patch I couldn't bootstrap, with your patch it works
[14:20] <mup> Bug #1531868 opened: Add network fails for multiple class B networks <MAAS:New> <https://launchpad.net/bugs/1531868>
[14:23] <mup> Bug #1531868 changed: Add network fails for multiple class B networks <MAAS:New> <https://launchpad.net/bugs/1531868>
[14:26] <mup> Bug #1531868 opened: Add network fails for multiple class B networks <MAAS:New> <https://launchpad.net/bugs/1531868>
[14:26] <dimitern> jam, awesome! thanks for giving it a go :)
[14:29] <mup> Bug #1531868 changed: Add network fails for multiple class B networks <MAAS:New> <https://launchpad.net/bugs/1531868>
[14:32] <mup> Bug #1531868 opened: Add network fails for multiple class B networks <MAAS:New> <https://launchpad.net/bugs/1531868>
[15:17] <mup> Bug #1531836 changed: Power state does not show on node using Digital Loggers PDU <power> <ui> <ux> <MAAS:Won't Fix> <https://launchpad.net/bugs/1531836>
[15:17] <mup> Bug #1531868 changed: Add network fails for multiple bigger-than-/24 networks in a single /16 <MAAS:Confirmed> <https://launchpad.net/bugs/1531868>
[16:02] <caturday> is there any way for me to tell in logs which preseed files, if any, a host used during commissioning?
[16:14] <mup> Bug #1531531 changed: 1.9 rc4: third-party driver not getting installed for storage device <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1531531>
[16:17] <mup> Bug #1531531 opened: 1.9 rc4: third-party driver not getting installed for storage device <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1531531>
[16:23] <mup> Bug #1531531 changed: 1.9 rc4: third-party driver not getting installed for storage device <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1531531>
[18:17] <badi> Hi All
[18:17] <badi> i have a sharp question
[18:17] <badi> about adding a redhat image
[18:58] <caturday> is there any way for me to tell in logs which preseed files, if any, a host used during commissioning?
[19:53] <dbainbri> is there a good "block diagram" for maas that indicates the various processes and how they communicate?
[20:06] <ltrager> dbainbri: theres this - https://maas.ubuntu.com/docs/orientation.html
[20:06] <ltrager> dbainbri: probably not as complete as your looking for though
[20:23] <dbainbri> ltrager: thx. it is a start. looking to understand how to run maas in a collection of containers.
[20:25] <caturday> does anyone here do anything with curtin preseeds?
[23:47] <dbainbri> when changes are made to the cluster, maas will update the dhcpd.conf file and restart the dhcpd process (i.e. cause a conf reload). is that accurate?