[05:02] <jtv> bigjools: can we just delete the install-pxe-bootloader provisioning command?  I'm worried about discarding UEFI work.
[05:02] <bigjools> jtv: leave it for now then, we can check to see what Blake is doing with it
[05:02] <jtv> Although... not a lot of changes from the UEFI work, actually.  All looks pretty superficial.
[05:03] <jtv> The only thing that's changed there is that it no longer says "PXE" in some places.
[05:04] <jtv> And a small change in path.
[05:06] <jtv> Ahhh, watch the problem cases disappear from my other branch, now landed.
[06:11] <bigjools> jtv: reviewing your branch
[06:13] <jtv> Thanks.
[06:27] <bigjools> jtv: done!
[06:28] <jtv> Thanks.
[06:28] <jtv> And the next one is up.  :)
[06:29] <bigjools> jtv: sheesh!
[06:29] <jtv> Hey, you're the one making me do work.
[06:29] <jtv> And unfortunately, your review comments will affect that one.
[06:31] <bigjools> I know :(
[06:31]  * bigjools afk for 15m
[06:52] <bigjools> jtv: quick chat about the config
[06:52] <jtv> OK
[06:53] <bigjools> talky
[08:26] <rvba> Hi jtv, question for you: does the conf gets rewritten even where no legacy config file can be found?  In a fresh install of the daily package, I get this: http://paste.ubuntu.com/7167249/.  It's okay… just weirdly formatted.
[09:17] <jtv> rvba: there is no legacy config file — just legacy boot images.  The rewrite always happens.  What you have there though means that the upgrade hook did find old boot images.
[09:18] <jtv> As for the formatting, the yaml module gives us a little bit of control over formatting but not much.
[09:18] <rvba> jtv: this is with a fresh install on canonistack.  No old boot image can have been found.
[09:18] <rvba> It's just not possible.
[09:20] <rvba> jtv: I understand we don't have much control over the formatting… I was just surprised to see the file being rewritten for a fresh install.
[09:20] <jtv> I told you.
[09:21] <rvba> "What you have there though means that the upgrade hook did find old boot images." that's the part I don't understand.
[09:21] <jtv> Ah, I figured out what happened.
[09:21] <rvba> Well, I understand but it doesn't make sense :)
[09:21] <jtv> I thought what you had there was the result of a rewrite based on existing boot images, because it wasn't the default config we had when I wrote the migration code.
[09:21] <jtv> But there's another explanation: the default config has changed since then.
[09:22] <jtv> What you have there looks like a different "spelling" of the new default config.
[09:22] <jtv> Labels were added, as was Precise.
[09:23] <jtv> I've been trying all day to get my test rig back up, but there were some problems.
[09:23] <jtv> Really weird one: with maas uninstalled, twistd still ran and used up tons of memory — on a machine with very little memory!
[09:23] <rvba> To me, it looks very much like the default config, just rewritten and thus weirdly formatted.
[09:24] <jtv> Yes, it's the new default config, as output by the yaml module.
[09:24] <rvba> Okay, I just didn't know the rewritting was supposed to always happen.
[09:25] <jtv> We talked about it in a merge proposal, but I guess you didn't see the part where I explained that.
[09:25] <rvba> No I didn't.
[09:26] <jtv> Sorry about that.  Yes, the rewrite always happens — if nothing else, to remove the configure_me marker.
[09:26] <rvba> I see.
[09:26] <rvba> Well, it's not the end of the world.  But the formatting is awkward.  I guess there is nothing we can do about it.
[09:27] <jtv> There's just one thing that I'm aware of: there's a boolean to control formatting.
[09:27] <jtv> Which doesn't give us a lot of options.  :)
[09:46] <dimitern> rvba, bigjools, hey, a quick question re gomaasapi and networks
[09:47] <dimitern> rvba, bigjools, if I call this inside the provider, will I be able to verify networks support in maas with certainty:
[09:49] <dimitern> rvba, bigjools, client := env.getMAASClient().GetSubObject("networks/"); result, err = client.CallGet("", nil) ?
[09:49] <dimitern> rvba, bigjools, the difficulty is "networks/" does not specify op=list like the other paths in the api supporting GET
[09:50] <jtv> dimitern: with networks, you just GET the "directory" URL to retrieve the listing.
[09:51] <rvba> dimitern: yeah, it's a bit inconsistent.  Some calls use op=list some use a plain GET with no 'op' parameter.
[09:51] <rvba> dimitern: but the proper way to do this now is to check the capabilities by requesting /version/.
[09:52] <dimitern> jtv, rvba, so CallGet("", nil) should either give me err=nil or some 404 or other error
[09:53] <jtv> Yes.
[09:53] <dimitern> thanks guys!
[09:54] <dimitern> rvba, is that /version/ working and released in 1.5 r1977 package i'm using?
[09:55] <rvba> dimitern: the new endpoint has been added in revision 2188.
[09:56] <dimitern> rvba, so I see https://bugs.launchpad.net/maas/+bug/1297814 got fixed
[09:56] <dimitern> even better!
[09:56] <rvba> dimitern: yes, in revision 2188.
[09:57] <rvba> dimitern: see https://lists.launchpad.net/maas-devel/msg01537.html
[09:59] <dimitern> rvba, awesome! thanks again for the quick response!
[11:12] <dimitern> rvba, looking at the daily-qa-ok ppa I can't see a newer package than 1.5+bzr1977+2115+246~ppa0-ubuntu14.04.1
[11:13] <dimitern> rvba, where should I get the package with /version/ support r2188?
[11:14] <dimitern> rvba, sorry, I found it in https://launchpad.net/~maas-maintainers/+archive/dailybuilds
[11:27] <rvba> dimitern: yes, the package in there has been QAed.  That's the one you should use.
[15:22] <rbasak> roaksoax: I see you touching bug 1298130. Do you still need me for anything on this one? I noticed that the test suite is disabled, and was looking into that.
[16:13] <roaksoax> rbasak: so there are a few thinsg that need to be fixed there in order to get it to the cloud archive tools pocket, since I'm trying to upload a new maas today
[16:14] <roaksoax> rbasak: I'll try to make an upload today that should leave the package in a good state for MIR, which you can take care of? that makes sense?
[16:15] <rbasak> roaksoax: sure. Let me know when you're done?
[16:15] <roaksoax> rbasak: will do! thanks for filing the MIR though
[16:33] <allenap> blake_r: Have you been able to do much QA on the UEFI stuff, especially since your last change yesterday?
[16:34] <allenap> rvba: What’s the workflow for selecting an HWE kernel now?
[16:40] <rvba> allenap: a hwe kernel = a subarch.  So you just assign the right arch/subarch to the node in question.
[16:42] <rvba> allenap: the kernel can come from simplestreams or you can put it manually (in the 'right' place, with files having the 'right' names — this probably ought to be documented) in /var/lib/maas/boot-resources/
[17:07] <basicer> Any idea how I can customize the partitions and filesystems curtin creates?
[17:09] <basicer> Id be willing to just have a shell script do all of it, but Im not sure what the section I would put it in would be?  early_commands: ?
[17:13] <roaksoax> rvba: is that documented? selecting hwe kernel?
[17:13] <roaksoax> basicer: check with smoser
[17:14] <roaksoax> allenap: we really need to QA UEFI, blake is testing curint now, d-i should just work
[17:14] <roaksoax> or well
[17:14] <roaksoax> he is verifying that d-i just works
[17:14] <roaksoax> and needs to fix curtin
[17:14] <dimitern> i found and filed bug 1299114 in r2188
[17:15] <smoser> basicer, documented... um... no
[17:15] <roaksoax> rbasak: https://launchpad.net/ubuntu/+source/python-seamicroclient/0.1.0-2ubuntu1 ok, so I uploaded that which should fixes various blockiers that prevent this from being backported into Cloud Tools pocket. Feel free to work against that to fix any thing you might need to fix for the MIR!
[17:15] <roaksoax> rbasak: thanks again for taking care of this
[17:15] <smoser> but if you have code that can do it, essentially waht you need to do is provide config that replaces the builtin's config that calls 'block-meta simple'
[17:16] <smoser> 'partitioning_commands': {'builtin': ['curtin', 'block-meta', 'simple']},
[17:17] <smoser> and then your code just needs to do what it does
[17:17] <basicer> And I just need to get it mounted to $TARGET_MOUNT_POINT ?
[17:19] <rbasak> roaksoax: ack. Thanks for sorting the tests - that's all I really needed for the MIR I think. I'll review.