=== CyberJacob is now known as CyberJacob|Away
=== mwhudson is now known as zz_mwhudson
[04:55] <Lord_Set> Greetings. So does anyone know if there are any planned projects or current projects with MAAS using the Cisco Nexus API to allow you to provision MAAS nodes into automatically created private vlans or networks and automate other network fuctions through the Cisco Nexus switch platform? I know this will get easier for KVM with the 1000V virtual switch for virtualization but there are a lot of
[04:55] <Lord_Set> applications and uses outside of virtualization as well.
[05:00] <jtv> Not being planned for 14.04, our current milestone.  Don't know about after; I know some people will be wanting things like that.
[05:02] <bigjools> Lord_Set: we were discussing it but no active plans right now
[05:02] <bigjools> would be a nice feature
[05:02] <bigjools> patches welcome :)
[05:04] <Lord_Set> Hello there bigjools. Guessing you are a MAAS dev?
[05:05] <bigjools> Lord_Set: both jtv and I are
[05:05] <Lord_Set> Awesome. Thanks again for the help the few times I have asked.
[05:05] <bigjools> welcome
[05:08] <Lord_Set> Like I have said before I think MAAS and Juju dominate Mirantis. So much better on so many levels. I just wish some of the features of the Mirantis portal and config page were in MAAS.
[05:08] <bigjools> Lord_Set: please file bugs for anything you would like to see
[05:09] <Lord_Set> I will. What do you use for your bug repository?
[05:09] <bigjools> https://bugs.launchpad.net/maas
[05:09] <Lord_Set> Thanks
[05:32] <jtv> bigjools: do you think there's any chance that this test failure might have happened because our signals restart named/bind too often and, say, run us out of ports?  https://code.launchpad.net/~jtv/maas/ui-node-networks/+merge/207632/comments/487817/+download
[05:33] <bigjools> jtv: entirely possible, but wtf is it happening now all of a sudden
[05:34] <bigjools> jtv: if that is the reason, my context manager is going to be quite useful :)
[05:34] <jtv> I'm not getting it either.  It's as if we're running some additional thread behind the tests.
[05:35] <jtv> I've got one very thin theory on why that other intermittent failure might have happened, but I'm clutching at straws: "maybe make_file() called time.time() for some reason."
[05:36] <bigjools> let me finish getting my head around this branch and then I'll look more closely
[06:20] <bigjools> jtv: any idea why post_save would have our callback in its receivers *twice* ?
[06:20] <bigjools> (Pdb) self._live_receivers(sender)
[06:20] <bigjools> [<function dns_post_save_NodeGroup at 0x302a5f0>, <function post_save_callback at 0x3032140>, <function post_save_callback at 0x3032398>]
[06:21] <bigjools> I think my change just exposed a bug
[06:24] <bigjools> oh, hahaha I see what's going on
[06:24] <bigjools> oh dear
[06:25] <jtv> ?
[06:27] <bigjools> both dhcp_post_edit_status_NodeGroup and dhcp_post_edit_name_NodeGroup get fired
[06:27] <bigjools> for this code:
[06:27] <bigjools>         nodegroup.name = new_name
[06:27] <bigjools>         nodegroup.save()
[06:27] <bigjools> no idea why
[06:34]  * jtv looks
[06:35] <bigjools> I'm digging
[06:35] <bigjools> pdb has been hot today
[06:35] <jtv> Doesn't look as if that should be firing...  unless maybe the value gets normalised during cleaning somehow.
[06:36] <jtv> I don't suppose the status gets updated while reconfiguring?
[06:36]  * jtv throws another we've-talked-about-this look in the direction of signals
[06:37] <jtv> Are you sure there were no other changes to that nodegroup?
[06:37] <bigjools> signals have caused much pain
[06:37] <jtv> But yes, I've observed some double-firing.
[06:37] <jtv> Yup.  What you'd call a pain signal.
[06:37] <bigjools> danger zone
[06:38]  * jtv gently drops the pun on the ground, raises his hands, and backs up 3 paces
[06:45] <bigjools> so the status changed when saving the name change
[06:45] <bigjools> wtf
[06:45] <bigjools> (Pdb) getattr(instance, delta_flag)
[06:45] <bigjools> ((1,), (0,))
[06:46] <bigjools> jtv: so somewhat stumped here
[06:47]  * jtv looks up those numbers
[06:48] <jtv> !
[06:48] <jtv> Oh noes
[06:48] <jtv> That's a change from Pending to Accepted.
[06:48] <jtv> So I think what's going on there is auto-acceptance.
[06:49] <jtv> Urgh
[06:49] <jtv> The factory method creates the NodeGroup (and it gets saved).  And _then_ it sets the status and some other properties, and saves again.
[06:49] <bigjools> oh bloody hell
[06:49] <bigjools> yes I remember seeing that earlier
[06:49] <bigjools> stupidity
[06:49] <jtv> No idea why we do that.  But expect more breakage.
[06:50]  * bigjools grinds teeth
[06:50] <jtv> I'm getting tired of doing that.  Know a good teeth-grinder?
[06:51] <bigjools> jtv: hang on
[06:52] <bigjools> why would it do this *here* when I do a node.save() in test code?
[06:52] <bigjools> this is not in the factory
[06:52] <bigjools> I bet this is because I tried to cheat the receivers...
[06:52] <jtv> And you're quite sure that the call isn't happening in the factory?
[06:52] <bigjools> it's the code I pasted above
[06:52] <jtv> How exactly are you cheating the receivers?
[06:53]  * bigjools makes WIP MP
[06:53] <bigjools> https://code.launchpad.net/~julian-edwards/maas/stop-dhcp-server-bug-1283114/+merge/207870
[06:53] <jtv> (I bet our test suite could be faster without the signals, too)
[06:54] <bigjools> yup
[06:54] <bigjools> so basically I'm just blanking the receivers while doing some stuff
[06:55] <jtv> Yuck...  post_save is a single global object with a receivers list!?  Are you sure?
[06:55] <bigjools> yep
[06:55] <bigjools> gross isn;'t it
[06:55] <jtv> Very.
[06:55] <jtv> I would expect the signals to be broken down by receiver type.  Which _would_ also explain what you're seeing.
[06:56] <bigjools> yeah you have another one somewhere I just noticed.  GRAR
[06:56] <bigjools> in fact 2
[06:56] <bigjools> I just want to smash signals in the face
[06:57] <jtv> Heyyy and what's this sender_receivers_cache?
[06:58] <jtv> I really think it would be cleaner to make the handlers do nothing by default in tests, and selectively enable them where relevant.
[06:58] <jtv> Like we did with DNS_CONNECT.
[06:58] <bigjools> it's grotesque
[06:58] <jtv> We _have_ done that with both actually...
[06:58] <bigjools> yep
[06:59] <bigjools> DHCP_CONNECT
[06:59] <bigjools> it is required here
[06:59] <jtv> So... shouldn't DHCP_CONNECT and DNS_CONNECT both be False in tests?
[06:59] <bigjools> I need to kill more signals
[06:59] <jtv> Yes, getting rid of them would be the ideal solution.
[06:59] <bigjools> no I need DHCP_CONNECT as it's testing the dhcp callbacks
[07:00] <bigjools> however the bloody factory causes more signals now I've fixed the underlying code
[07:00] <bigjools> hence my context manager
[07:00] <jtv> Shouldn't you just leave the enabling of DHCP_CONNECT to the last moment?
[07:01] <bigjools> it does
[07:01] <bigjools> but makes no difference to the f*@!ing signals
[07:02] <jtv> But surely the actual handler exits immediately when DHCP_CONNECT is not set..?
[07:06] <bigjools> jtv: oh good grief I can see what';s going on
=== CyberJacob|Away is now known as CyberJacob
[07:06] <jtv> ?
[07:07] <bigjools> jtv: the code was relying on DHCP_CONNECT being false to return a [] from get_interfaces_managed_by
[07:07] <bigjools> but my code ploughs on regardless now
[07:07] <bigjools> this is such a grotesque hack
[07:12] <jtv> Wouldn't it make more sense to start the handler with "if not DHCP_CONNECT then give up"?
[07:17] <bigjools> jtv: eminently so
[07:17] <bigjools> which is what I just did
[07:28] <bigjools> rvba: I hope my needs-fixing made sense?
[10:09] <melmoth> hi there. I have been asked to help someone using maas about a "slowiness in the region controller syslogd" when one use juju add-machine
[10:09] <melmoth> i do not have much information to be honest...But, is this sort of thing, common, or ring a bell to anyone ?
=== matsubara is now known as matsubara-afk
[12:34] <hazmat> hi folks, just curious wrt to progress on vlan stuff
=== fader_ is now known as fader
[14:16] <manishanker_> Hi i am new to MAAS .I am trying to install MAAS in Ubuntu 12.04 LTS . i have succeded in installing .Once i log in to the Dashboard ,i keep getting this error  The region controller does not know whether any boot images have been imported yet. If this message does not disappear in 5 minutes, there may be a communication problem between the region worker process and the region controller. Check the region worker's logs for signs
[14:17] <jpds> manishanker_: That's not an error.
[14:17] <jpds> manishanker_: And you've forgetten to run: sudo maas-import-pxe-files
[14:17] <manishanker_> Sorry
[14:19] <roaksoax> manishanker_: http://maas.ubuntu.com/docs/install.html#import-the-boot-images
[14:19] <manishanker_> i ran the command still i am getting that error
[14:21] <jpds> Did you wait five minutes like it tells you? :)
[14:21] <manishanker_> Yes i did :P
[14:21] <manishanker_> I have a query regarding Region controller
[14:28] <manishanker_> I have installed MAAS and its components on server -a . Can i add its Mac address while i am creating nodes or do i have to add mac address of other servers ?
[14:31] <roaksoax> manishanker_: if the machines PXE boot off MAAS dsirectly, you can just let them register themselves automatically
[14:31] <roaksoax> you wouldn't have to add any machine
[14:32] <manishanker_> Thanks roaksoax
[15:18] <manishanker_> quit
[16:27] <fader> Hmm, is there a minimum amount of RAM needed to run MaaS?  I have a VM with 4G and it's getting OOMs after 3-4 minutes when I run the code from trunk
[16:27] <fader> Not sure if that's a leak or if you just really need more RAM
[16:39] <roadmr> fader: I'm using 4GB on my maas controller and it works just fine
[16:39] <roadmr> fader: based on "free" output, 2 GB should also work
[16:39] <roadmr> fader: (this is from packages available for trusty, though)
[16:39] <fader> roadmr: Yeah, that's what I thought, as I've got a controller with 4GB running some older (released) version of maas
[16:40] <fader> So probably a leak somewhere, hopefully not in the code I was trying to hack into it :)
[16:43] <roadmr> you broke it :P
[16:43] <fader> I don't *think* I did :)  I'm going to blame med_ for no good reason.
[16:44] <med_> perfect
[16:44]  * med_ reads scrollback a bit
[16:44] <fader> :)
[16:44] <med_> morning fader.
[16:44] <med_> (well, morning out here in the West)
[16:44] <fader> med_: Morning!  (Still here too for another 15m)
[16:44] <med_> maas controller is typically a VM
[16:45] <med_> so be surprising if it took killer amounts of RAM but not too surprising if it was a seive for memory containtment
[16:45] <med_> fader, if you are running "pure" upstream *unhacked* you'd want to bug file that issue.
[16:46] <fader> med_: Yeah, I was afraid of that :/  Going to try a clean branch and make sure I still see that behavior
[16:46] <fader> (I'm pretty sure nothing I touched would have done it but might as well be sure)
[16:46] <med_> nodz.
[16:47]  * med_ shouldn't even be in this channel...
[16:48] <fader> med_, roadmr: Since you guys are around and might know, what's the process for submitting patches for maas?  I don't see anything in the hacking guide
[16:48] <fader> Is it just submit a merge request on lp?
[16:49] <med_> roaksoax, ^
[16:49] <fader> Ta
[16:50]  * med_ truly doesn't know..... 
=== matsubara-afk is now known as matsubara
=== roadmr_ is now known as roadmr
[18:17] <bjf> i have maas importing pxe files now. how can i get the maas ui to add trusty as one of the options to install on new nodes?
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
=== Guest70848 is now known as wallyworld
=== CyberJacob is now known as CyberJacob|Away