| === blackboxsw is now known as blackboxsw_away | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === uru__ is now known as urulama | ||
| gnuoy | jamespage, another review for a LS blocking bug if you have a moment https://code.launchpad.net/~gnuoy/charm-helpers/bug1354471/+merge/230593 | 09:01 |
|---|---|---|
| jamespage | gnuoy, merged | 09:38 |
| gnuoy | thanks | 09:38 |
| gnuoy | jamespage, I've created a bunch of mp to sync charm-helpers into the next charm to pickup the srcpkgcache fix from earlier if/when you have a moment | 14:04 |
| jamespage | gnuoy, if its just a resync then auto +1 | 14:04 |
| jamespage | merge away | 14:04 |
| gnuoy | jamespage, Mostly it is, on a few I've added the charmhelpers sync smarts and I had to fix a unit test in the keystone charm | 14:05 |
| gnuoy | are you happy for me to go ahead with all of them ? | 14:05 |
| jamespage | gnuoy, yes | 14:05 |
| gnuoy | thanks | 14:05 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| mfa298 | I've been playing with a small ceph cluster using three nodes (using the ceph) charm. I pulled one node out with a juju remove-unit ceph/1 altered the hardware (added drives and changed network cards around), recommisioned in maas and then rebuilt is as a new unit however it doesn't seem to be rejoining the cluster and the mon list on the other nodes hasn't updated. any suggestions as to what to look at | 15:08 |
| jamespage | mfa298, hmm - pulling part of the mon quorum like that is probably not a great idea | 15:21 |
| jamespage | I'm not sure the cluster bootstrap process will support that | 15:21 |
| mfa298 | that doesn't bode well for running something similar in production | 15:22 |
| mfa298 | If a node failed I'd want to be able to replace it easily | 15:22 |
| jamespage | mfa298, I'd need to check | 15:22 |
| gnuoy | jamespage, I have a similar set of updates for the stable charms (add | 15:27 |
| gnuoy | charm helper smarts and sync) | 15:28 |
| gnuoy | should I create mps for those ? | 15:28 |
| jamespage | gnuoy, yes pls | 15:28 |
| gnuoy | will do, ta | 15:28 |
| mfa298 | it also looks like the replacement node isn't setting up extra OSDs | 15:57 |
| === jcw4 is now known as jcw4|away | ||
| mfa298 | jamespage: any thoughts on how I might be able to fix that ceph cluster. | 17:39 |
| mfa298 | could one (drastic) option be to delete the ceph service, then re-create it with the format-osd option set to off ? | 17:40 |
| mfa298 | I'm assuming that would then recreate it and find the existing OSDs to use | 17:40 |
| jamespage | mfa298, you have two service unit remaining right? | 17:53 |
| mfa298 | yes | 17:53 |
| mfa298 | The plan was to change out the hardware on all three but do one at a time and wait for things to re-sync so the cluster kept quorum | 17:54 |
| jamespage | mfa298, looking at the code, I can't see why introducing a new ceph service unit would not initiate it correctly into the cluster | 17:55 |
| jamespage | mfa298, I wonder if its something todo with reuse | 17:55 |
| jamespage | mfa298, let me test somehting | 17:55 |
| mfa298 | the OSD drives changed (although I still have the original) but I wiped the OS drive and the interface being used to build it from maas changed (was on a 10G card I wanted for something else) | 17:57 |
| mfa298 | although I didn't wipe the box from maas (just did a re-commision) but I don't think that should have caused an issue | 17:57 |
| jamespage | mfa298, so the new mon daemon is joining OK? | 18:17 |
| jamespage | mfa298, OK - so here is what I just tested successfully | 18:22 |
| jamespage | small three node ceph cluster; destroyed and terminated one of the nodes via juju, added a new node | 18:23 |
| jamespage | bootstrapped into the cluster OK - appeared in MON list, new OSD inserted | 18:23 |
| jamespage | I had to remove the old node OSD and MON entries via the command line | 18:23 |
| jamespage | that I would expect; | 18:23 |
| === ming is now known as Guest61014 | ||
| === perrito6` is now known as perrito666 | ||
| mfa298 | that sounds similar to what I did | 18:51 |
| mfa298 | I had three nodes, each running MON and OSD, I did juju remove-unit ceph/1 and juju terminate-machine 22 to remove the node | 18:54 |
| mfa298 | then changed bits of hardware then did juju add-unit ceph to add it back in. IP of the node then changed as the hardware had changed. | 18:55 |
| mfa298 | As it's the same machine in MAAS but using a different interface I wonder if the maas and juju side have got confused (I found maas remembering old IP's once before when it probably shouldn't have) | 18:57 |
| mfa298 | juju status is showing the node as started but it doesn't seem to have created the OSD and it didn't update the ceph config for the new mon IP (although it sounds like you had to change some of that manually from what you said) | 18:59 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| ctlaugh | The openstack-dashboard charm (among others) seem to overwrite /etc/network/interfaces and create a bridge with eth0. My MAAS preseed file had previously enabled eth1 as well, but now it is not getting enabled. Is there a way to get both eth0 and eth1 up without the charm(s) undoing it? | 20:03 |
| === jcw4|away is now known as jcw4 | ||
| jamespage | mfa298, I think its some sort of confusion | 21:00 |
| jamespage | possibly due to the IP change | 21:00 |
| jamespage | mfa298, I did not update any ceph configuration files - the operations I did where using the cli tools to ceph mon rm <oldmon> and some similar things for the old osd references | 21:01 |
| mfa298 | the ip changing confusing things seems likely | 21:02 |
| mfa298 | I've not manually run any ceph commands, I was hoping juju would handle it all but it seems like that might be the route to take. | 21:03 |
| mfa298 | I might try removing it fully from juju and maas first tomorrow and see if that makes it recover at least then hopefully everything will thinks it's a completely new node. | 21:04 |
| mwhudson | why does the maas provider move eth0 onto a bridge? | 21:09 |
| jamespage | mwhudson, for use with LXC or KVM containers | 21:16 |
| jamespage | mwhudson, its a little raw | 21:16 |
| mwhudson | jamespage: ctlaugh is trying to use it on nodes with two nics | 21:17 |
| mwhudson | and it seems to be messing things up | 21:18 |
| jose | mbruzek: how is that thing that you cannot promulgate a charm without an icon? since when have we had this problem? | 21:53 |
| mbruzek | jose, I don't know how long we have had it but now the promulgate command runs charm proof and halts on anything W and E | 21:55 |
| jose | mbruzek: I'll open a thread about it, seems nonsense to me | 21:55 |
| mbruzek | The cakephp charm looked good to me otherwise. | 21:55 |
| jose | we do have charms without icons in the store atm | 21:55 |
| mbruzek | jose I already took this up with marcoceppi | 21:55 |
| jose | yeah, I quite liked how it got there | 21:56 |
| jose | mbruzek: oh, I'll leave it there, then. keep me informed on the output, please :) | 21:56 |
| marcoceppi | jose: it's always been policy | 21:56 |
| marcoceppi | you can't promuglate without proof passing | 21:56 |
| marcoceppi | proof has just evolved overtime | 21:56 |
| jose | marcoceppi: you told me without Es, but nothing about Ws | 21:56 |
| mbruzek | jose I really wanted to approve the cakephp charm | 21:56 |
| jose | I don't see anything bad on a warning | 21:57 |
| jose | in this case, for example, it's throwing a warning because there's no icon due to the author asking for permission to the organization | 21:57 |
| jose | and... it's just an image. I agree, it may not look awesome in the GUI, but Juju is about services, and in this specific case it deploys it perfectly and runs awesome | 21:59 |
| marcoceppi | jose: there's nohing stopping the author form creating a temporary icon | 22:24 |
| marcoceppi | for the time being | 22:24 |
| === CyberJacob is now known as CyberJacob|Away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!