bdxhows it going everyone?01:06
bdxim running 1.8.0+bzr4001-0ubuntu2~trusty101:07
bdxon trusty 14.04.301:07
bdxcore: I'm having MAJOR issues with nodes not being able to reboot after a storage disk replacement01:10
bdxcore: I'm experiencing this issue when I replace an osd disk on any ceph storage node and then reboot it01:11
bdxany* osd disk01:12
bdxcore: 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 further01:14
bdxcore: 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 eventually01:20
bdxsuccessfully boots.01:20
bdxcore: the other work around -> swap the newly replaced disk out with the original that was initially replaced01:22
bdxcore: 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 disks01:28
bdxalso....the second work-around is really not01:31
bdxbecause it just returns the node to the original state so it can boot01:31
bdxI'll post this to the lists if no one on here has any ideas!01:33
=== mup_ is now known as mup
mupBug #1466852 changed: doesnt wait long enough for release power off on power <MAAS:Expired> <https://launchpad.net/bugs/1466852>04:22
mupBug #1468408 changed: cannot release, or delete node from maas ui <maas-cli> <maas-ui> <MAAS:Expired> <https://launchpad.net/bugs/1468408>04:22
gnuoyI have a cluster whose images are out-of-sync. In the maas.log I see06:55
gnuoy"maas.import-images: [WARNING] I/O error while syncing boot images. If this problem persists, verify network connectivity and disk usage"06:56
gnuoyboth network connectivity and disk space seem fine. Where can I look to further diagnose this?06:56
=== wojdev_ is now known as wojdev
mupBug #1488558 opened: maas 1.7 client (in trusty) cannot login to 1.8.0 server <MAAS:New> <https://launchpad.net/bugs/1488558>15:42
mupBug #1488558 changed: maas 1.7 client (in trusty) cannot login to 1.8.0 server <MAAS:Invalid> <https://launchpad.net/bugs/1488558>16:21
mupBug #1488589 opened: make 'current' symlink in /var/lib/maas/boot-resources relative , not full path <MAAS:New> <https://launchpad.net/bugs/1488589>17:21
mupBug #1488593 opened: Unable to add AMT machine to MAAS 1.8.2 <MAAS:New> <https://launchpad.net/bugs/1488593>17:21
mupBug #1488594 opened: Nodes cannot boot after a storage disk replacement <ceph> <disaster-recovery> <storage> <MAAS:New> <https://launchpad.net/bugs/1488594>17:21
mupBug #1488593 changed: Unable to add AMT machine to MAAS 1.8.2 <MAAS:Triaged> <https://launchpad.net/bugs/1488593>18:15
bdxany takers on this https://bugs.launchpad.net/maas/+bug/148859419:59
mupBug #1488649 opened: Can't set a specific API key through the API or UI <oil> <MAAS:New> <https://launchpad.net/bugs/1488649>20:22
=== menn0_ is now known as menn0
mupBug #1488684 opened: power on option available while system is deploying and already powered on <oil> <MAAS:New> <https://launchpad.net/bugs/1488684>23:04
jamesgaohi, 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:11
jamesgaotgt is running properly on the server23:12
jamesgaoboth machines are within libvirt / kvm, in an attempt to test this setup before we deploy on physical hardware23:12

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!