=== hazmat` is now known as hazmat === vladk|offline is now known as vladk === CyberJacob|Away is now known as CyberJacob === vladk is now known as vladk|offline === vladk|offline is now known as vladk === CyberJacob is now known as CyberJacob|Away [08:21] gmb: that file was part of the simplestreams code drop, which lacked tests. [08:21] We did some of the most basic cleanup, and there's an end-to-end test, but more unit tests are still needed. [08:32] gmb: loads of that import code is untested, we're adding it as we go [09:02] jtv: perhaps if you have some time you might want to take a look [09:02] https://code.launchpad.net/~julian-edwards/maas/report-subarches-in-bootimage/+merge/219987 [09:02] at least someone please give me something I can work on tomorrow :) [09:03] bigjools: is this just because when I commented on it earlier it was in the wrong channel, which _you_ picked? [09:03] Or is this a different one? [09:03] gmb: btw, I just noticed that you used django's BinaryField in BootSource. It's all right but it means we now have 2 different BinaryFields in use: the one we created (back when the other one did not exist) and the one provided by Django. [09:04] jtv: same one [09:04] If we had time, I'd love to look into abolition of our home-grown BinaryField... [09:04] jtv: doesn't need to be you, just *someone*, please! [09:04] Yeah, that would be great. [09:04] bigjools: I'll have a look later today. [09:05] bigjools: as I said, needs documentation. :) [09:05] jtv: next branch [09:06] OK. One thing that's still sadly lacking is a mention of what that meta file is _for_. [09:06] (And if you're going to chide me for the terminal preposition, up shut) [09:08] jtv: an abomination up with which I shall not put [09:08] On which, spot. [09:08] It's awkward and off it pisses me. [09:09] I shall pop in some comments to explain for what the file is used [09:09] Huh what? [09:09] Oh, I see what you did there... [09:30] bigjools: I think extract_image_params suffers a bit from the vagueness of that term "params." It makes you call individual elements of params "param" despite it containing multiple parameters. [09:30] Is there no more specific name you can give each of those dicts? [09:30] jtv: yes, like I said, the branch needs some tidying [09:30] it has evolved somewhat [09:31] Just adding specifics, because you needed things to work on... [09:31] just bear in mind this is nothing I've added :) [09:32] AFAICS "param" is new. [09:32] oh that bit yeah [09:33] well the function name started it I supposed [09:33] extract_image_params is returning a variable called... params. Fancy :) [09:35] I need to EOD now, rather tired [09:35] all that coding has left me exhausted! [09:35] Good night! [09:35] thanks for looking at the branch [09:35] I appreciate your comments [09:36] Apart from the one about your face, obviously. [09:36] Good night. :) [09:36] you said nice things about it once [09:37] You mean the one where it was too high for me to see? :) [09:37] or maybe that was in one of your dreams [09:37] * jtv wonders how bigjools would hear him talk in his sleep... [09:37] I am turning this PC off now before this gets too exciting [09:37] *chuckle* [09:37] cheerio :) [09:38] nn [10:14] gmb: arg, it's getting worse: a BinaryField is non-editable. Which means we can't use forms to accept base64-encoded input to change the value of that field. [10:16] rvba: Damn. [10:17] gmb: I'll figure a way… but it will require changes to the model… [10:17] Yeah. [10:17] rvba: So, what about (this is horrible) storing the keyring data as a (base64-encoded) string, and using a file upload field to get the keyring data in there (and then dealing with the file behind the scenes). [10:17] Could that work with the API/CLI? [10:17] * gmb doesn’t know whether we do file-stuff already within the CLI. [10:18] I seem to remember the CLI supports file upload now… [10:18] It does [10:18] gmb: it would be better to figure out a way that work with Django's binary field though. [10:19] works* [10:19] rvba: Definitely. I’ll happily defer to your Django experience rather than my hacktastic approach :). [11:01] gmb: BootSource.objects.get_boot_sources_for_cluster() takes more typing than doing the query yourself. Maybe we should just have a 1:n attribute on NodeGroup. [11:02] jtv: Totally WFM. [11:02] jtv: I’ll stick a card on the board. [11:02] Low priority though. :) This is tech debt. [11:02] Fairly easy to pay off. [11:03] Yeah. [11:03] jtv: Actually, IIUI, it should be there already as NodeGroup.bootsources_set. [11:03] But I’d forgotten that when I wrote the function :) [11:04] Might be, actually. I forget whether that needed any work. [11:04] I think it’s automatic. [11:21] * gmb -> Dinner (by which I mean Northern ‘dinner,’ which Southerners call “Lunch”). [11:22] * jtv very confuse [11:32] gmb: I think I spotted another problem. We use a FilePathField for BootSource.keyring_filename. If you have a look at the doc you'll see that this will validate against the *region*'s file system. Where in fact this file only has meaning in the context of the cluster. [11:39] I thought it was intended for use to refer to a region-side file..? [11:39] IIRC the region then reads that file and sends the _contents_ to the import code. [11:44] Then I don't understand why we have bot a keyring_filename and a keyring_data field. [11:44] both* [11:46] My understanding was: if you set a filename, it will get read from the filesystem every time the imports are run, which means the keyring could come with a package, and get automatic updates. [11:46] Whereas if you have a custom keyring, you can pass the keyring contents centrally and have the import code use that instead, and you manage updates yourself. [11:46] But I'm only guessing, really. [11:47] That would make sense. I'll let gmb confirm that it's what he had in mind. [11:47] And document. :) [11:48] jtv: then I guess we need to think about migrating the config from the cluster's config file to the region's DB. Because the meaning of the keyring_filename is changing (from a file on the cluster to a file on the region). [11:49] I thought the plan was not to migrate those files. [11:49] So, use the default? [11:49] Yes, download the world. [11:50] (For Precise/Trusty). [11:50] With a UI for those who want to pare it down. [11:50] I see. [12:01] gmb: could you also confirm to us that there is no plan to migrate existing bootresources.yaml files? I've been working on the assumption that we always start off with The World. [12:01] (Things get a lot more complicated otherwise.) [13:07] gmb: I see there's a card for removing parts of bootresources.yaml. I'd just leave the file alone until we delete it. Changing it further only invites yet more conflicts during upgrade. [13:09] jtv: +1; that card’s from before I knew what we needed to do :) [13:09] OK [13:09] And can you confirm that we have no plans to migrate existing bootresources.yaml settings? It wasn't meant to be very end-user-ish anyway, so I'm not sorry. [13:10] The initialisation code I have up for review gives a user a clean slate, even after upgrading. [13:21] * jtv steps out for real [14:03] * gmb -> switching locations [14:57] allenap, gmb, rvba: I get the impression that "./bin/test.pserv provisioningserver.import_images.tests.test_boot_resources" actually downloads images... [14:57] Belt, braces, and belly. [14:57] It goes into the ppc64el boot method, whose install_bootloader starts downloading. [15:11] allenap, gmb, rvba: fix is included in https://code.launchpad.net/~jtv/maas/no-bootresources-rewrite/+merge/220046 — who will review it for me? [15:13] jtv: +1d [15:14] Thanks! [15:39] gmb: does the plan for ditching bootresources.yaml involve migrating existing config? [15:54] jtv: It doesn’t ATM. It definitely *could*, whether it’s an absolute necessity I’m not sure. [15:54] (I wonder how many people will have touched their bootresources.yaml) [15:55] I see some complications, e.g. "should we also try to migrate from pre-existing images" and "must we go through an API exchange right before importing, just for this upgrade?" [16:02] gmb: the API work for boot source is up for review. [16:02] rvba: I saw. Thanks :). That’s going to be a nice task to take me to EoD :) [16:02] gmb: good luck :) [16:02] gmb: I'm sure you can leave some of it for Julian. [16:03] Now there’s a thought… [16:06] gmb: NodeGroup.bootsource_set. :) === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === CyberJacob|Away is now known as CyberJacob === vladk is now known as vladk|offline === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === roadmr is now known as roadmr_afk === vladk|offline is now known as vladk [19:56] not getting impi after installing 14.4 maas, and commisioning servers | http://askubuntu.com/q/469306 === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === roadmr_afk is now known as roadmr === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === CyberJacob is now known as CyberJacob|Away