[07:03] <rvba> bladernr_: Hum, that's interesting… I'll try recreating this…
[07:12] <rvba> Hi jtv and thanks for the review… reading you essay now :).
[07:12] <rvba> your*
[07:20] <rvba> jtv: Weird, https://code.launchpad.net/~jtv/maas/lint-2014-04-21/+merge/216578 is not landing…
[08:01] <jtv> rvba: I had a case like that the other night... lemme see if that landed.
[08:01] <jtv> (Didn't look then because it was just lint)
[08:01] <jtv> Nope, not landed!
[08:58] <rvba> bladernr_: I cannot reproduce your problem: see paste.ubuntu.com/7305538/
[09:05] <rvba> allenap: forgot to ask you.  Did you start working on producing the documentation for the power parameters as you said you would?
[09:06] <rvba> I'm asking because it's quite essential if we want to let maas-test take arbitrary power parameters.
[09:08] <allenap> rvba: No, I didn’t. I ended up working on house stuff about 16-18 hours a day for several days instead. I was more exhausted than I have ever been :)
[09:09] <rvba> allenap: no worries.  But I had to ask.  Are you still planning on getting that done?
[09:10] <allenap> rvba: I’d like to, but if you’re at a loose end and you want to do it, go for it. Tbh, I have to concentrate on planning for Austin for the next week or so.
[09:12] <rvba> allenap: all right.  I guess I'll take of it then.
[09:14] <rvba> take care*
[11:12] <jtv> rvba: did you come up with an answer to the pop quiz?
[11:14] <rvba> jtv: not yet… I need to think about it… this is obviously a trick question :)
[11:15] <jtv> Obviously.  :)
[12:29] <rvba> gmb: if you still have that setup, could you please check what's up with our lander (and maybe tear it down and start another if push comes to shove)?  None of the approved branches are landing on trunk.
[12:52] <gmb> rvba: Sure thing.
[12:52] <rvba> Ta
[12:52] <gmb> Bear with me.
[13:05] <gmb> rvba: Hmm. Tarmac got stuck. Looking into it now.
[13:09] <gmb> rvba: running tarmac manually now, then it should get back to normal. Looks like it got stuck on the 18th and hasn’t done anything useful since.
[13:11] <gmb> Wow. Holymegatestfailure Batman!
[13:32] <jtv> gmb: that test failure looks like the old "the API client package is installed when it shouldn't be."
[13:33] <gmb> jtv: Mmm, could be; looks like all the branches are failing in the same way.
[13:33] <gmb> jtv: I’ll wait for tarmac to finish puking.
[13:33] <gmb> And then sort it out.
[13:33] <jtv> Yeah.  It's what happens when you switch from developing maas to working on maas-test, and back again.
[13:34] <gmb> Blech.
[13:34]  * gmb wonders if we should have a make target that checks for a lack of the API client package and bails out early.
[13:35] <gmb> If the tests are just going to fail anyway…
[13:35] <jtv> I think Gavin did something like that recently.
[13:35] <gmb> Aha.
[13:35] <gmb> allenap: ^^??
[13:35]  * allenap reads
[13:35] <jtv> See required-packages/forbidden
[13:35] <gmb> Eeenteresting.
[13:35] <jtv> Ah, but not in there.
[13:36] <allenap> Yes, that’s the one.
[13:36] <gmb> Strangely enough, the api client package is not installed.
[13:36] <jtv> There was another one like that I think.
[13:37] <gmb> Oooh, hang on…
[13:37]  * jtv hangs on
[13:37] <gmb> There’s cruft left in the copy of maas-trunk that tarmac has.
[13:37] <gmb> I wonder if that’s the cause…
[13:37] <gmb> Must have been left behind by the stuck tarmac run.
[13:37] <gmb> Hmm.
[13:38]  * gmb cleans up, runs tarmac again
[13:41] <gmb> Hmm. Nope, still kaboomey
[13:41]  * gmb might just kill the machine and start a new one.
[13:42] <jtv> It's the Cloud Way™.
[13:45] <gmb> Yeah.
[13:51] <gmb> FWIW, looks like everything’s failing with “AttributeError: 'functools.partial' object has no attribute '__module__’”
[13:51] <gmb> Maybe not everyting… there’s a lot of noise.
[14:13] <bladernr_> rvba: not sure what to tell you... I completely deleted everything (rm -rf ./boot-resources/* and re-synced using the bootresources.yaml (after commenting out everything I didn't need) and I ended up with both RC and Release images... I got that both before and after clearing the boot-resources dir.
[14:13] <bladernr_> rvba: I can try again, but it takes me several hours due to living on a slowish DSL line
[14:21] <rvba> bladernr_: can you paste your bootresources.yaml?  And tell me which version of MAAS you're using?
[14:23] <rvba> bladernr_: I'm testing things on canonistack, where it takes less than 10 minutes to sync a couple of images.
[14:23] <bladernr_> rvba: http://paste.ubuntu.com/7307356/
[14:23] <bladernr_> should all be in there
[14:24] <bladernr_> the only changes I made to bootresources.yaml was to comment out the older stuff because I only need images for Saucy and Trutsy
[14:24] <bladernr_> Trusty even
[14:25] <rvba> bladernr_: you don't have 'labels' defined for any of your selections.  The default value is '*' which means: take all the labels you find.
[14:25] <rvba> That's your problem.
[14:26] <bladernr_> that's the way the package installed it.  When I did the upgrade from Saucy, I told it to install the new packaged version of bootresources.yaml
[14:26] <rvba> Okay, this an upgrade bug then.
[14:26] <bladernr_> So I ended up with bootresources.yaml (new) and bootresources.yaml.dpkg-old (my original)
[14:27] <bladernr_> where would I add "labels" to my current file then?
[14:27] <bladernr_> under sources: labels: release ??
[14:28] <bladernr_> ^^ at the top along with the keyring and path declarations?
[14:28] <rvba> bladernr_: paste.ubuntu.com/7307395/
[14:29] <bladernr_> ahhh... ok.
[14:29] <bladernr_> that was going to be my next question, actually... is it possible to specify per release, so I could have lables: -release for 14.04 and -daily or whatever for 14.04.1 then?
[14:30] <bladernr_> thanks, I'll fix mine and restart the import and see what happens.
[14:31] <rvba> This is all based on simplestreams' data and, AFAIK, there is no separate stream for 14.04.1.  So the answer would be 'no.'  You might want to double check that with Smoser though.
[14:34] <smoser> bladernr_, what do you think that 14.04.1 means ?
[14:34] <smoser> i'm not being pedantic, its an important piece of information .
[14:34] <bladernr_> well, I would think that 14.04.1 is not 14.04 (ISOs should be different)
[14:35] <bladernr_> from a cert standpoint, we don't do package upgrades, we do installs from daily or release ISOs, so 14.04 ISOs != 14.04.1 ISOs and BOTH are install options
[14:35] <bladernr_> using 12.04 for example, when we'd do a cert, we'd start with 12.04.1 and test, then install 12.04.2 and test, then 12.04.3 and test and so forth
[14:36] <bladernr_> that MAY change with 14.04, assuming there won't be two different fully supported kernels like we ahve in 12.04, but I don't know how that's going to work yet
[14:36] <smoser> right. so 14.04.1 is 2 things, that are actually completely disjoint.
[14:36] <smoser> a.) a media release of a point in time snapshot of the archive.ubuntu.com
[14:36] <smoser> b.) a selection of different default kernel.
[14:37] <bladernr_> c.) any hardware enablement work up to that point that isn't backported (either in software bits or kernel bits)
[14:37] <bladernr_> AIUI, there will be no backported hardware enablement, (I coudl be wrong)
[14:37] <smoser> what is 'b' that is not 'c' ?
[14:38] <smoser> for 'a', maas has no way to do address this. changes in simplestreams wont help that. you need a time machine or something like snapshot.debian.org .
[14:38] <bladernr_> software bits, not kernel bits... so possible to have something like... newly packaged RAID config tools based on 14.04.1 kernel but incompatible for some reason with 14.04 kernel
[14:38] <smoser> not really.
[14:38] <smoser> thos would just be packages in the archive.
[14:38] <bladernr_> fair point.
[14:39] <smoser> for 'b', we have that addressed now.
[14:39] <smoser> in 14.04.1 time frame, you will see a
[14:40] <smoser> com.ubuntu.maas:v2:boot:14.04:amd64:hwe-u
[14:40] <smoser> entry appear in http://maas.ubuntu.com/images/ephemeral-v2/releases/streams/v1/com.ubuntu.maas:v2:download.sjson
[14:40] <smoser> it will also be labeled "release"
[14:40] <bladernr_> cool
[14:40] <smoser> but will have "subarch" as "hwe-u".
[14:41] <smoser> you can see that right now with 12.04 things.
[14:41] <smoser> there is hwe-p, hwe-q, hwe-r ...
[14:45] <bladernr_> ok.  to be honest, I would like to get away from how we were doing testing (multiple ISO images) anyway... and the HWE kernel thing is more a regression testing / SRU testing thing than cert... so that will work fine
[14:45] <bladernr_> IMO
[14:45] <bladernr_> If course, people who get paid more than I do may think otherwise :)
[15:08] <jtv> gmb: any luck with that lander?
[15:14] <jtv> smoser: can you think of a reason why uec2roottar might print "finished. wrote to [etc]" but still return nonzero?
[15:15] <jtv> Looks highly implausible, no?
[15:15] <jtv> I'm trying to figure out why that was the last stderr output I got from it, around the time that the maas logs show the command failing.
[15:16] <jtv> Ahhhhh, it's not uec2roottar that failed.
[15:17] <jtv> It's my attempt to "sudo chown" what I think is the output file.
[15:19] <jtv> Why on earth would that fail?
[15:19] <jtv> "sudo chown maas:maas <root-tgz-file>"
[15:19] <jtv> Ahhhh
[15:19] <jtv> sudoers.
[15:27] <gmb> jtv: I started a new one but because of the way they’re configured OOTB I can’t SSH to it… So, no.
[15:29] <jtv> :(
[15:30] <smoser> jtv, you may be able to just create the expectecd target file with the perms.
[15:30] <smoser> maybe
[15:31] <smoser> prior to calling it.
[15:31] <smoser> i dont like that, but as a work around it might work.
[15:32] <jtv> Six of one...  It might make more sense to have a wrapper that does both, and give sudo rights to run that script.
[15:32] <jtv> Instead of sudo rights to run uec2roottar followed by chown.
[15:33] <jtv> Anyway, I'm out.  Good night!
[17:22] <roaksoax> /q/win 10
[18:56] <bigtree> What files do I need to delete to download the newest images? I am starting MaaS and on my nodes I am seeing the development branch of trusty being installed.
[19:30] <magicrobotmonkey> soo my nodes not booting, it keeps hanging on cannot connect to iSCSI daemon. Is there a log on the server I can see?
[20:01] <allenap> rvba: Is it deliberate that the remote API docs are only generated for trunk, wrt https://maas.ubuntu.com/
[20:01] <allenap> ?
[21:52] <qhartman> Anyone have pointers to docs for running up nodes that are multi-homed? My hardware keeps coming up with only the management interface (eth0) configured. Even if eth1 would come up via dhcp I'd be happy. Is the right thing to adjust the pre-seed file?
[21:53] <qhartman> If that's the case, I assume that there is some analogue for the fastpath installer?
[22:08] <ser_> Hi! After installing MAAS from Ubuntu Server 14.04 boot media can't get the web address.Didn't ask  web address that will be used to the web interface. What is the problem?
[22:20] <qhartman> it should be whatever the IP of the server for your MAAS installation
[22:21] <qhartman> specifically http://maas-server-ip/MAAS
[22:46] <ser_> Thank you