[01:06] <bdx> hows it going everyone?
[01:07] <bdx> im running 1.8.0+bzr4001-0ubuntu2~trusty1
[01:07] <bdx> on trusty 14.04.3
[01:10] <bdx> core: I'm having MAJOR issues with nodes not being able to reboot after a storage disk replacement
[01:11] <bdx> core: I'm experiencing this issue when I replace an osd disk on any ceph storage node and then reboot it
[01:12] <bdx> any* osd disk
[01:14] <bdx> core: immediatly after pxe boot the console of the node will show a "disk uuid mismatch" error message and will not continue the boot process any further
[01:20] <bdx> core: it seems the only work arounds I've found to get a node to boot after a storage disk replacement is to momentarilly disable maas from managing the network after a power on of the node, following that, after the node pxe boot times out and it results to booting from local disk into the os, I re-enable maas management on that network so the node gets an ip and continues the boot process and eventually
[01:20] <bdx> successfully boots.
[01:22] <bdx> core: the other work around -> swap the newly replaced disk out with the original that was initially replaced
[01:28] <bdx> core: it would be nice to get some feedback on what is going on here, and also a best practice for what/how to proceed in the case when you need to swap storage disks
[01:31] <bdx> also....the second work-around is really not
[01:31] <bdx> because it just returns the node to the original state so it can boot
[01:31] <bdx> lol
[01:31] <bdx> srry
[01:33] <bdx> I'll post this to the lists if no one on here has any ideas!
[01:33] <bdx> thanks!
[04:22] <mup> Bug #1466852 changed: doesnt wait long enough for release power off on power <MAAS:Expired> <https://launchpad.net/bugs/1466852>
[04:22] <mup> Bug #1468408 changed: cannot release, or delete node from maas ui <maas-cli> <maas-ui> <MAAS:Expired> <https://launchpad.net/bugs/1468408>
[06:55] <gnuoy> I have a cluster whose images are out-of-sync. In the maas.log I see
[06:56] <gnuoy> "maas.import-images: [WARNING] I/O error while syncing boot images. If this problem persists, verify network connectivity and disk usage"
[06:56] <gnuoy> both network connectivity and disk space seem fine. Where can I look to further diagnose this?
[15:42] <mup> Bug #1488558 opened: maas 1.7 client (in trusty) cannot login to 1.8.0 server <MAAS:New> <https://launchpad.net/bugs/1488558>
[16:21] <mup> Bug #1488558 changed: maas 1.7 client (in trusty) cannot login to 1.8.0 server <MAAS:Invalid> <https://launchpad.net/bugs/1488558>
[17:21] <mup> Bug #1488589 opened: make 'current' symlink in /var/lib/maas/boot-resources relative , not full path <MAAS:New> <https://launchpad.net/bugs/1488589>
[17:21] <mup> Bug #1488593 opened: Unable to add AMT machine to MAAS 1.8.2 <MAAS:New> <https://launchpad.net/bugs/1488593>
[17:21] <mup> Bug #1488594 opened: Nodes cannot boot after a storage disk replacement <ceph> <disaster-recovery> <storage> <MAAS:New> <https://launchpad.net/bugs/1488594>
[18:15] <mup> Bug #1488593 changed: Unable to add AMT machine to MAAS 1.8.2 <MAAS:Triaged> <https://launchpad.net/bugs/1488593>
[19:59] <bdx> any takers on this https://bugs.launchpad.net/maas/+bug/1488594
[19:59] <bdx> ?
[20:22] <mup> Bug #1488649 opened: Can't set a specific API key through the API or UI <oil> <MAAS:New> <https://launchpad.net/bugs/1488649>
[23:04] <mup> Bug #1488684 opened: power on option available while system is deploying and already powered on <oil> <MAAS:New> <https://launchpad.net/bugs/1488684>
[23:11] <jamesgao> hi, i'm having trouble with a test of maas i'm running -- all the nodes always get stuck on a lengthy sequence of "iscsistart: connect to __ (connection refused)"
[23:12] <jamesgao> tgt is running properly on the server
[23:12] <jamesgao> both machines are within libvirt / kvm, in an attempt to test this setup before we deploy on physical hardware