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