=== allenap_ is now known as allenap
=== Guest9121 is now known as wallyworld
=== mscheel` is now known as mscheel
=== CyberJacob|Away is now known as CyberJacob
=== CyberJacob is now known as CyberJacob|Away
[09:16] <dimitern> anyone around? I'm having issues with getting maas cli ipaddresses to work
[09:16] <dimitern> $ maas maas-root ipaddresses reserve network=192.168.50.0/24
[09:17] <dimitern> No network found matching 192.168.50.0/24
[09:18] <dimitern> but I can see 192.168.50.0/24 in the networks list with $ maas maas-root networks read
[09:19] <dimitern> roaksoax, allenap, gmb, rvba`, if you have a moment? ^^
[09:21] <dimitern> jtv, bigjools, blake_r, jhobbs, or maybe one of you? ^^
[09:23] <allenap> dimitern: I’m here, but I have less experience than you with that command :)
[09:23]  * allenap fires up NUC.
=== rvba` is now known as rvba
[09:24] <dimitern> allenap, ah :), sorry to bug you, but it seems the command accepts some format I'm not getting or there may be a bug
[09:35] <gmb> allenap: What’s the nicest way to test the way a function handles an error in an RPC call? Is it to set the side_effect of the RPC call (when using MockLive*Fixture) to defer.fail(Exception(….)) or am I missing something? That way doesn’t quite work the way I expected.
[09:35] <jtv> dimitern: is the cluster interface set to manage DHCP?
[09:35] <dimitern> jtv, let me check
[09:35] <jtv> And more importantly, does it have a static range set?
[09:35] <dimitern> jtv, yes: eth0	192.168.50.0/24	Manage DHCP and DNS	
[09:36] <jtv> And the static range?
[09:36] <dimitern> jtv, hmm, that might be it - how to check?
[09:36] <jtv> Because that's where the static IP address comes from.
[09:36] <jtv> Look at the cluster interface in the UI.
[09:36] <jtv> (Well, or the API, but UI is easier.)
[09:36] <dimitern> jtv, there's nothing in the Non-MAAS DHCP column
[09:36] <jtv> That's OK.
[09:36] <jtv> That's just a check for rogue DHCP servers on the network.
[09:37] <jtv> But click on to the page for that specific interface, and you should see a dynamic address range and a static address range.
[09:37] <jtv> If it only has the dynamic range, then you can't reserve static IP addresses because there's no address range to take them from.
[09:38] <dimitern> jtv, it indeed did have only dynamic ranges, I added static low-high, but the cluster edit page still does not show anything in Non-MAAS DHCP
[09:38] <jtv> Are you running a DHCP server on that subnet that's not managed by MAAS?
[09:39] <dimitern> jtv, nope, maas is running inside kvm on a dedicated bridge, so it's isolated from the rest of the network
[09:39] <dimitern> jtv, and after adding the static range it did work! thanks!
[09:40] <jtv> The Non-MAAS DHCP field is there only to show you if there are any DHCP servers running on the subnet that MAAS isn't in charge of.  Empty is its normal, "everything OK" state.
[09:40] <dimitern> jtv, I see
[09:40] <dimitern> jtv, but I have to note that as a dumb user the "No network found matching 192.168.50.0/24" error message when there's no static range set isn't very helpful :)
[09:41] <jtv> Indeed.
[09:41] <jtv> File a bug?
[09:45] <dimitern> jtv, will do, thanks
[09:49] <allenap> gmb: Sorry, I missed your question until now. /me thinks.
[09:49] <gmb> No worries
[09:50] <allenap> gmb: Yeah, set side_effect.
[09:50] <allenap> gmb: What’s not working quite right?
[09:52] <dimitern> bug filed: https://bugs.launchpad.net/maas/+bug/1367197
[09:52] <ubot5> Ubuntu bug 1367197 in MAAS "maas-cli ipaddresses reserve network=CIDR error message unhelpful" [Undecided,New]
[09:53] <bigjools> jtv. dimitern: I was *just* looking at the code that does that 10 minutes ago and thinking... hmm this will give the wrong error!  And guess what ...
[09:53] <gmb> allenap: http://paste.ubuntu.com/8298444/ produces  http://pastebin.ubuntu.com/8298451/
[09:53] <jtv> bigjools: told you it'd make more sense to match on the full network before checking against just the static range.  :)
[09:53] <bigjools> jtv: meh
[09:54]  * bigjools goes afk
[09:54] <dimitern> bigjools, :) indeed
[09:55] <dimitern> dogfooding IS king
[09:55] <allenap> gmb: I’s investigatin'
[09:56] <gmb> Ta
[09:59] <allenap> gmb: I can’t apply that to trunk. Do you mind merging trunk and diffing again?
[09:59] <gmb> Gnargh.
[09:59] <gmb> allenap: Sure
[10:00] <gmb> (As in “Sure, no problem,” not “yes, I mind, you cheeky swine."
[10:01] <gmb> allenap: http://paste.ubuntu.com/8298498/
[10:02] <gmb> allenap: or lp:~gmb/maas/create-node-to-use-RPC
[10:09] <allenap> gmb: I think mock is getting confused over the use of both return_value and side_effect. http://paste.ubuntu.com/8298529/ is my fix.
[10:09] <gmb> allenap: Ah, sweet. Thanks.
[10:10] <gmb> allenap: Also, didn’t know you could have a list of side_effects. Nice!
[10:12] <allenap> gmb: Yeah, I didn’t know that until relatively recently.
[10:12] <dimitern> allenap, gmb, re that bug I filed, is it hard to change the error message in that case?
[10:12] <dimitern> I mean it's something that will probably hit us sooner rather than later, however trivial it might seem
[10:13] <dimitern> so IMHO it should be triaged as High perhaps
[10:16] <bigjools> dimitern: it's not trivial to fix
[10:17] <bigjools> priority reflects the reality of when it will get fixed, not how important it is
[10:17] <dimitern> bigjools, I see, ok then
[10:17] <bigjools> having said that, I'll take a look tomorrow
[10:18] <dimitern> bigjools, thank you ever so much :)
[10:18] <bigjools> :)
[12:40] <jtv> caribou: yes, "bzr branch," commit & push changes, then "propose for merging" into lp:maas.
[12:41] <caribou> jtv: work is done on the upstream branch or the Ubuntu one (i.e. lp:ubuntu/maas) ?
[12:43] <caribou> jtv: I have another question but I'll ask in the Freenode channel
[12:43] <caribou> oh, I am now
[12:44] <caribou> man I need to figure out a way to discriminate b/w two channels with the same name
[12:45] <caribou> ok, I'm working on another bug : when installing maas-cluster-controller, the postinst script runs "chown -R /var/log/maas"
[12:45] <caribou> in doing this, it changes the ownership of /var/log/maas/rsyslog & the syslog daemon can no longer write to it
[12:47] <caribou> would the following change to the postinst script be adequate for you : http://paste.ubuntu.com/8299594/
[12:47] <jtv> caribou: the work is done on the upstream branch.
[12:48] <caribou> jtv: perfect!
[12:48] <jtv> I guess /var/log/maas needs syslog as its group then..?
[12:49] <caribou> jtv: before installing maas-cluster..., the ownership is correctly set to syslog:syslog
[12:50] <caribou> jtv: the maas-region-controller.postinst script does it correctly
[12:50] <caribou> jtv: it is just the blanket change by "chown -R" in the maas-cluster pkg that messes things up
[12:51] <jtv> Oh, what you're proposing is already in the region postinst?
[12:52] <caribou> jtv: no, the region sets up /var/log/maas as owned by syslog:syslog, but then installing the maas-cluster behind it resets it to maas:maas
[12:52] <jtv> Do we know that maas will still be able to do all the logging it needs, e.g. after log rotation?
[12:53] <caribou> jtv: so if I do the normal "apt-get install maas", /var/log/maas/rsyslog is owned by maas:maas & the syslog daemon cannot write to it
[12:53] <caribou> jtv: if I only install the maas-region-controller package (for testing purpose), then /var/log/maas/rsyslog is owned by syslog:syslog
[12:53] <jtv> Yes, so the question is: will the cluster controller be able to log when it's like that?
[12:54] <caribou> jtv: well, doing the 'find .' in http://paste.ubuntu.com/8299594/ will change everything bug rsyslog to maas:maas so I suppose that it will work
[12:55] <caribou> jtv: one thing is sure : /var/log/maas/rsyslog when owned by maas:maas doesn't work
[12:55] <jtv> Right.
[12:56] <jtv> I guess it'll work in either installation order?
[12:56] <jtv> (Sorry, evening here, tired!)
[12:57] <caribou> jtv: no worry, it's not obvious out of the context
[12:58] <caribou> jtv: I'll propose a branch & test my stuff before hand. then you people can judge
[12:58] <jtv> If comments are possible, add them!
[12:58] <jtv> Thanks.  :)
[13:00] <caribou> jtv: thank you
[13:00] <jtv> Don't thank me.  You're the one writing the patch.  :)
[13:46] <caribou> hmm, the change I was talking about previously is in a debian packaging specific file; should I do the MP from the lp:ubuntu/maas branch ?
[14:10] <lamont> if tcpdump shows the ipmi packets going from the controller to the ilo on the HP DL 360 blade, and it doesn't power on, what are the most likely suspects?
[14:34] <gmb> allenap: Calling allenap-as-a-service… Why does http://paste.ubuntu.com/8300331/ give me http://paste.ubuntu.com/8300352/?
=== kickinz1` is now known as kickinz1|afk
[14:42] <gmb> allenap: Nevermind. Fixed it.
[14:44] <gmb> allenap: Oh, wait, no I haven't.
=== kickinz1|afk is now known as kickinz1
[15:19] <rvba> gmb: I was surprised to see https://bugs.launchpad.net/maas/+bug/1357071.  I thought we were using a wrapped around system calls but apparently, this is coming straight from the Python library… any idea on how we could fix this?  I'm asking because I'm not sure Blake's big replacement is going to be done in time for the release.
[15:19] <ubot5> Ubuntu bug 1357071 in MAAS "When a power template fails, the content of the event from the node event log is not readable (it contains the whole template)" [High,Triaged]
[15:29] <gmb> rvba: I have no clever ideas off the top of my head… bear with me a sec.
[15:29] <gmb> allenap: I’m completely stuck with the problem I pung you with last. Whenever you’ve got a chance to eyeball it, it’d be appreciated.
[15:34] <gmb> rvba: I need some context. Where in the code is that error actually coming from?
[15:37] <rvba> gmb: that's the thing, I tried to change ExternalProcessError.str (or whatever it's called) and couldn't get a different representation of the error.
[15:38] <gmb> !
[15:38] <rvba> gmb: then I hacked /usr/lib/python2.7/subprocess.py:CalledProcessError and *this* changed the error
[15:39] <gmb> Ooo-kay
[15:39] <rvba> That's why I was surprised, I thought we were using a wrapper each time we need to shell something out.
[15:42] <gmb> rvba: Well, isn’t the offending code in src/provisioningserver/power/poweraction.py?
[15:42] <gmb> That doesn’t use our wrapper (why? IDK)
[15:42] <gmb> It uses subprocess directly.
[15:43] <gmb> rvba: See PowerAction.run_shell()
[15:43] <gmb> rvba: So maybe a first step is to change that to use our call_and_check wrapper.
[15:44] <rvba> gmb: yeah, probably.
[15:44] <rvba> gmb: I was just wondering why we didn't use that already.
[15:45] <gmb> rvba: No clue, I’m afriad. We (I?) must’ve missed that when switching things over to use call_and_check.
[15:47] <gmb> allenap, rvba, blake_r, jhobbs: https://code.launchpad.net/~gmb/maas/create-node-to-use-RPC/+merge/233899 needs a review, please.
[16:01] <blake_r> gmb: done
[16:01] <gmb> blake_r: Thx
=== kickinz1 is now known as kickinz1|afk
[16:59] <gmb> allenap: You’ve got a bunch of cards in the review lane for celery removal, but I don’t see any branches… are those ones all done, or am I jumping the gun?
[17:14] <gmb> Yay, test isolation problems!
[17:14] <gmb> But they’re for tomorrow.
[17:44] <allenap> gmb: They’re reviewed, just not landed yet.
=== roadmr is now known as roadmr_afk
=== kickinz1|afk is now known as kickinz1
=== kickinz1 is now known as kickinz1|afk
=== CyberJacob|Away is now known as CyberJacob
=== roadmr_afk is now known as roadmr
=== jfarschman is now known as MilesDenver
=== jfarschman is now known as MilesDenver