=== wgrant_ is now known as wgrant [01:01] bigjools or jtk you around? [01:01] yup [01:02] Do you have any good examples of comissioning scripts? [01:02] I have examples, you might not call them good [01:02] One of our developers was looking to see some examples [01:02] Any example will work [01:04] if you look in the code metadataserver/models/commissioningscript.py [01:04] the built-in scripts are there [01:04] Ok thanks [01:38] Hi, are there any samples of custom commissioning scripts, i.e. user defined scripts. E.g. I'm trying to install webmin, custom packages, after installation of a node. [01:39] ? [01:39] svetmy: commissioning scripts are not for installation tasks [01:39] you need to use cloud-init scripts for that [01:46] Lord_Set: did your friend see my response? [01:48] svetmy: hello you pinged out, did you see my response? [01:48] no, sorry, could you pl repost? [01:48] svetmy: commissioning scripts are not for installation tasks [01:48] you need to use cloud-init scripts for that [03:11] jtv1: was your randomly failing test this one? [03:11] FAIL: maasserver.views.tests.test_rpc.RPCViewTest.test_rpc_info_when_rpc_running [03:11] No. === jtv1 is now known as jtv [03:12] I filed: [03:12] https://bugs.launchpad.net/maas/+bug/1283918 [03:12] Ubuntu bug 1283918 in MAAS "Intermittent test failure: test_wait_script_waits_for_lldpd" [High,Triaged] [03:12] https://bugs.launchpad.net/maas/+bug/1284418 [03:12] ok [03:12] Ubuntu bug 1284418 in MAAS "Intermittent test failures in TestDNSConfigModicfications: "dig" returns 9" [High,Triaged] [03:12] trying another run [03:13] jtv: I am ->this<- close to doing a mass rename of DHCP_CONNECT and DNS_CONNECT [03:13] because what it actually means is, RUN_DHCP_JOBS === mwhudson is now known as zz_mwhudson [04:15] I wish there were a way to speed up the build. It's getting tediously slow. [04:21] which build? [04:22] "make" [04:22] In a maas branch. [04:22] mine is quick enough [04:22] are you pulling deps every time? [04:22] That's what it seems to be doing, yes. [04:23] I have a trick for you [04:23] ~/.buildout/default.cfg: [04:23] download-cache = /home//.buildout/cache [04:23] eggs-directory = /home//.buildout/eggs [04:23] mkdir ~/.buildout [04:23] gvim ./buildout/default.cfg [04:23] Anything else that needs to go in there? [04:23] sigh :) [04:24] you're welcome [04:24] Do we have this documented anywhere? [04:24] doubt it [04:25] Until we finally ditch buildout, I mean... [04:25] we're moving away from buildout [04:25] are you using a sandbox checkout as well? [04:25] which makes things ever moar quickerer [04:25] Well let's see about getting this set up first... [04:25] After that, I'd be ecstatic to speed it up even more. [04:26] ok I'm going to eat, I'll explain on my return [04:26] Thanks. [04:34] bigjools: the buildout config needed a section header, but with that, I'm down to 8 seconds. Thanks! [05:05] jtv: woops yes sorry [05:05] jtv: can speed it up more though [05:05] I use no-tree branches [05:06] and have a single lightweight checkout with the files [05:06] and use bzr switch to change branches [05:26] i have maas importing trusty pxe files now. how can i get the maas ui to add trusty as one of the options to install on new nodes? [05:26] bjf: you probably need a newer version [05:27] bigjools, a newer version of MAAS ? i've installed the stock saucy, do i need to switch to the cloud archive? [05:27] bjf: umm, saucy doesnt know anything about trusty, no [05:28] you need a trusty maas running on trusty [05:28] bigjools, but in the future i'll always want to be able to install the current development seris [05:29] bigjools, as one of the options [05:30] bjf: unless someone invents a time machine that won't be possible I'm afraid [05:31] I think there's an outstanding bug to support this but it's not high priority [06:09] bigjools: get_interfaces_managed_by actually grew out of is_dhcp_managed_by, which had the DHCP_CONNECT check in it. [06:09] is_dhcp_managed_by was originally is_dhcp_managed. [06:11] So the DHCP_CONNECT check has been in there for years — I just had to change it from returning a boolean to returning a set of managed interfaces. [06:11] (And no, I didn't write the original :) [06:21] jtv: ok :) === CyberJacob|Away is now known as CyberJacob [08:40] rvba: I'd be quite interested to know how you're fixing the scaling on the node/MAC multi-selection widget! [08:40] jtv: well, I'm not fixing the whole problem, just part of it. [08:41] jtv: making the widget usable when we have hundreds of MAC is doable (that's what I'm doing). [08:41] jtv: make the widget usable when we have tens of thousands of MACs is another story. [08:41] s/make/making/ [08:42] The worry there is of course not so much that the widget won't work well, because people aren't going to do that stuff manually. The problem there I think is that the page will have trouble loading. [08:43] jtv: yes indeed, with tens of thousands of MACs the page will be horribly slow, if not completely broken. [08:44] I'll just add a separate card for that. [08:44] jtv: What I think we should do is remove the widget entirely if we have more than, say, 500 MACs. [08:44] That'd do it... [08:44] Replace the whole widget with a message saying to use the API. [08:47] Or a widget on the Node page. [08:48] But, yes, at scale the API is the more systematic answer. [08:48] Stepping out for a bit. [09:08] rvba: we need two widgets IMO [09:16] bigjools: the second widget (the one that can cope with a lot of MACs) would have to be developed from scratch I'm afraid. It's a lot of work for very little gain. [09:16] rvba: it doesn't need to cope with a lot of MACs [09:16] we need a node picker, which when picked, sets up the MAC picker [09:16] thereby narrowing down the selection [09:17] could even do cluster -> node -> mac [09:17] The first picker will need to cope with a lot of nodes. [09:17] We're down to the same pb. [09:17] yes but picking nodes is easier as we can make it work like the tag picker on LP [09:17] you can search on name [09:17] presenting hundreds of nodes to click on is not useful [09:18] Right, it's definitely possible. But it's not trivial. [09:18] this is an interesting problem - I am inclined to defer it actually rather than rushing :/ [09:18] Interesting / JS [09:18] E_CONTRADICTION [09:18] :) [10:56] bigjools: Ping. [10:57] Anyone have any idea how I can debug this? http://people.canonical.com/~jpds/cannot-find-disk.png [11:20] jpds: not really, but the error itself is not specific to MAAS. [11:21] Some people on the internet seem to be getting that error, but not a lot... From what I see it looks like it might be a hardware problem of some sort. [11:22] Here's someone whose MBR looks to have been corrupt, leading to this error message: http://www.experts-exchange.com/Hardware/Storage/Q_26451031.html [11:23] Well, the machine had just gone through the fastpath installer. [11:24] roaksoax or smoser might be able to help. === edamato is now known as edu-afk === CyberJacob is now known as CyberJacob|Away [15:31] jpds: is this after a system install? [15:31] jpds: that's either 1. MAAS is telling them to LOCALBOOT to the wrong location [15:31] or parameter really [15:32] or 2. The disk where the installation is is different? [15:32] jpds: i'd suggest looking at the localboot pxe template [15:33] roaksoax: I think UEFI is doing something funny. [15:34] maybe === roadmr_ is now known as roadmr === zz_mwhudson is now known as mwhudson [20:50] Greetings [20:50] How is everyone today? === Settite is now known as Lord_Set === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob