[00:11] Bug #1524120 opened: 1.9rc3: Pressing after entering MAC when creating new interfaces cancels input [02:51] Bug #1524152 opened: [1.10] Upgrade failts [04:21] Bug #1460204 changed: Upgrade leaves rogue maas-regiond process [04:21] Bug #1460678 changed: MAAS writes logs to /var/log/maas/maas.log.1 [15:59] How is maas expected to behave in the event of a power outage, for example? [16:00] I have a lab that had to be taken offline last night, and I *thought* I had seen this just work before, and everything came back how it was after the power was restored [16:01] but in this case, it appears that the maas server first changed the state of all nodes from deployed to ready, powered them off, and then commissioned them [16:02] I tried turning one on through maas, and it just said that it was unable to power on the machine and to change my selection. I tried powering it on remotely through the pdu, and it just flipped it back off for me [16:02] I can always redeploy everything of course, just trying to avoid that if I don't need to [16:03] and more importantly, I'd like to know what is the right way of dealing with situations like this in the future [17:02] matsubara: ^ Any ideas? or recommendation who to ask? [17:03] plars, roaksoax or blake_r [17:05] plars, I don't know what is the correct behavior in that situation. I think maas would have kept the state it had before everything was shutdown. Maybe the nodes were rebooted and pxe booted again rather than boot from the deployed disk? [17:05] matsubara: that's what it looks like, which was a bit surprising to me [17:05] but that shouldn't happen, AFAICT, once it's deployed, I think the node is set to not try to pxe boot again [17:06] one thing you could try is to power on the node through the PDU and through its console try to boot from the disk rather than allowing it to pxe boot [17:07] and then see what happens [17:07] but if they were commissioned again t might have changed the state maas knew about them [17:10] matsubara: I don't have direct access to them, they are in taipei [17:11] matsubara: I could get someone to try it tonight, but I need to recover it all before then [17:11] matsubara: just trying to use this time to see if I can determine what went wrong here, and how it could have been avoided [17:17] Bug #1524419 opened: DHCP on unmanaged network interface overrides the DNS entries of the MAAS controller [17:20] Bug #1524419 changed: DHCP on unmanaged network interface overrides the DNS entries of the MAAS controller [17:23] Bug #1524419 opened: DHCP on unmanaged network interface overrides the DNS entries of the MAAS controller [17:26] Bug #1524419 changed: DHCP on unmanaged network interface overrides the DNS entries of the MAAS controller [17:29] Bug #1524419 opened: DHCP on unmanaged network interface overrides the DNS entries of the MAAS controller [17:31] plars, sorry, don't know how else to help. Might be helpful to provide logs from maas server and one of the nodes to one of the devels (but you'd need access to the machines to get those out...) [17:32] matsubara: let me see what I can dig up, thanks [17:32] Bug #1524419 changed: DHCP on unmanaged network interface overrides the DNS entries of the MAAS controller [17:33] I'm just redploying at the moment [20:17] Bug #1524482 opened: [xenial,1.10] Error when updating network interface [20:20] Bug #1524482 changed: [xenial,1.10] Error when updating network interface [20:26] Bug #1524482 opened: [xenial,1.10] Error when updating network interface [20:47] Bug #1524042 changed: [xenial,1.10] Fail on clean install - missing /usr/bin/twistd [20:47] Bug # opened: 1524498, 1524500, 1524501, 1524502 [22:33] Bug #1523919 changed: MAAS missing dependency