=== CyberJacob is now known as CyberJacob|Away [01:47] bigjools: we can just make maas-test import from the daily images and ignore the releases repo, right? [01:47] jtv: hmm good question [01:47] I would say both, but default to release [01:49] Maybe we can have a chat about this? [02:24] hm [02:24] how do you configure maas-dns? [02:37] mwhudson: maas generates the dns config using a template (in /etc/maas/templates IIRC) [02:37] So you edit the template. [02:37] hm [02:38] what i want to do is tell it where to forward most requests to [02:38] like e.g. "python.org" [02:38] Ah, that's already a thing. [02:38] For some quantity of thing. Let me look. [02:38] i don't know much about configuring dns [02:40] So what you want to set is the “upstream” DNS, for all requests for hostnames not managed by the MAAS, right? [02:41] yes [02:41] There's a UI setting for that. Look for "upstream DNS." [02:41] oh UI [02:42] i wonder why the UI isn't responding [02:42] At all..? [02:42] just hanging [02:42] bet it turns out to be a firewall [02:42] Then why did it work before though? Maybe a big ongoing upgrade? [02:43] hm? [02:43] it's never worked for me [02:43] on this install [02:43] which is a day old [02:45] you can set it via the API too, it's just a config item [02:51] ah ok i think the api not working was a stale ip address [02:53] shouldn't maas createadmin prompt for a password? [02:53] here we go again :) [02:53] createsuperuser does [02:53] or maybe the docs should be fixed, if it's that sigh-worthy :) [02:53] people keep asking for one and then the other [02:54] one is django's command, one is our wrapper [02:54] bigjools: http://maas.ubuntu.com/docs/install.html#create-a-superuser-account seems to be just wrong (for trusty anyway i guess?) [02:54] yeah the docs will be updated when 1.5 is released [02:55] and we'll have docs for each supported release, at last [02:55] separate docs I mena [02:55] mean [02:55] i don't see a setting for dns in the ui :/ [02:55] oh that will be nice [02:55] it's on the config page somewhere [02:56] this maas install seems less fresh than i thought it was :/ [02:57] heh [02:57] 2230 is latest trusty [03:01] is it possible that this maas doesn't think it's managing dns? [03:01] 1.4+bzr1693+dfsg-0ubuntu2.2 [03:01] ok that's ancient? [03:01] mwhudson: ancient! [03:01] ffs [03:01] that's cloud-tools or saucy's version [03:02] only about 500 revision behind [03:02] oh [03:02] this vm is saucy [03:02] ffs [03:19] anti-progress: the dns server i want to forward to does not, in fact, appear to be listening to me [03:22] winning [04:11] jtv: is there anything else in your branch that needs attention? [04:11] I will approve it [04:14] I hit a different problem in Q/A; part that worked before. May just be my experimental change. [04:49] I always knew the uploading of the file would be the hard and risky part, but why did it work when Raphaël tried it? [05:02] jtv: what goes wrong? [05:04] Oh, I see it now. The scp command. [05:10] jtv: let me guess, quoting? [05:10] No, just a missing username/host prefix. [05:11] I guess Raphaël fixed that up in his experiment. === vladk|offline is now known as vladk [05:17] ahah [05:19] Yup, that seems to work. [05:19] I'll try another Q/A run. [05:43] Hmm... images are imported just fine now (and according to spec), but Raphaël's new poll-until-images-are-imported code hits a timeout. [05:44] So report_boot_images is not working in some way. [05:45] Or maybe it's just genuinely taking too long. [05:49] Ah, wouldn't surprise me — he switched over from running the import script to triggering a run from the API. [05:49] The script doesn't return until the import is done, and from there all we need to wait for is for report_boot_images to run. [05:49] But when we call the API for importing images, it returns immediately — and so what we're waiting for is completion of the import itself. [05:50] (No longer report_boot_images, because the API-triggered task runs that right after the import). [05:50] The timeout is 10 minutes, IIRC, which is fine for the report_boot_images cycle — but maybe not for the import. [05:50] jtv: so, is it working or not? :) [05:50] Not yet, not yet! [05:51] Can't wait to have some hardware for this stuff... [05:54] No, no, the change that triggers the API version of the imports doesn't seem to have landed yet... [06:14] Ahhh, found the cause: chmod. [06:14] Another easy fix. [06:32] My branch just passed the enlist-a-node test. [06:36] \o/ Test successful. Landing. === CyberJacob|Away is now known as CyberJacob === vladk is now known as vladk|offline [07:09] bigjools, is this what you had in mind? https://code.launchpad.net/~jtv/maas-test/daily-option/+merge/215088 [07:10] jtv: boolean params always pique my interest [07:11] they are nearly always better replaced with some sort of enumerated value [07:11] Very true, but it's the UI choice that matters here. [07:11] --image-type= [07:11] What happens under the bonnet can be changed easily. [07:11] ? [07:11] and default to "release" [07:11] ? [07:12] then it stays a little looser [07:12] I have similar misgivings about calling things types of things. There are usually different aspects that you could call types. [07:12] ok [07:13] This option is just a shortcut for an alternate config... easier to improve once a real pattern forms. [07:13] it was a rough suggestion, I'm open to options [07:13] you *could* just take a whole simplestreams path [07:14] Yeah, but it's a lot more work for the user. I figured that could be a next step in making it more flexible — if we need it. [07:14] but remember that this API needs to stick after bootresources is gone [07:15] I see that as a reason to keep the UI as simple as possible: keeps it easy to change the whole implementation, even if we may later have to build a more flexible, more complicated way of doing the same thing. [07:15] Not hard to say "you can't specify --daily-images and a custom path" later, if/when we add an option for the latter. [07:15] the mass-test UI would have to change if a new "type" was introduced [07:15] it would not have to change in maas [07:15] see my point? [07:16] Wait... what's the connection to maas? [07:16] I mean, maas would never know about any of this anyway. [07:17] maas itself just cares about the url to the index [07:17] "path" in the config [07:17] Yes, that's what I mean. [07:17] it knows nothing about dailies/release [07:17] I think maas-test should be the same [07:17] And that's the way I like it. [07:17] me too [07:17] We can do that, but getting the right URL has been a bit of a pain in the past. [07:18] You know: "I have a URL to an index listing here, but how many path components do I need to strip off to get the URL that simplestreams wants?" [07:19] my suggestion is to default the whole URL and allow knowledgeable users to override as they want [07:19] dailies won't get used much after release, everyone will want to know if trusty works on their hardware [07:19] Okay. It's an easy change — I just figured it was hard on the users. [07:20] I would normally agree but I think the frequency of using this option will be limited to power users [07:20] What should I call the option then? --image-stream? [07:20] --image-stream-url [07:20] ? [07:20] OK [07:20] cool, thanks [08:50] rvba: if you want to use the API for starting the import job, that'll work now — but don't forget that the timeout for the BootImage records to appear will then have to cover the import time, not the report_boot_images interval. [08:50] jtv: not sure it's worth doing right now tbh. It's a cleanup that can be done later. [08:51] OK, just a thing to keep in mind. [08:51] Yeah. [08:51] Because 10 minutes is a long, long time for the report_boot_images schedule... but not a lot of time to import images! [08:51] A very useful cleanup would be to avoid downloading the i386 images when it's not necessary. [08:51] Maybe I'll fix that. [08:52] That'd be great — look for "mipf" in the function name, in utils.py IIRC. [08:52] allenap: bigjools: jtv: gmb: just a reminder (in case I forget): just before the release we want to change the label of the Trusty images from 'daily' to 'release'. [08:52] That's what says "oh you asked for armhf? I'll give you armhf/generic and throw in i386/generic as well." [08:52] I know. [08:53] Change the label? Of already imported images you mean!? [08:53] No, the label for Trusty in /etc/maas/bootresources.yaml. [08:53] So Scott is going to throw the switch? [08:55] We probably need to get confirmation from him that the 'release' images for Trusty have been published. [08:56] Since AFAIR _all_ the images in the daily stream were labelled "daily," shouldn't we just use label "*"? Saves us worrying about synchronicity. [08:57] Doesn't make a great difference. We would still have to change the 'path.' [08:58] Is he going to change that as well!? [08:59] ISTM we can just put trusty under the "releases" source. [08:59] And just leave the label as *. [08:59] ISTM we can do that before the upstream data changes, with no ill effects. [09:00] rvba: we need to change that ASAP well before the FF. If there's a problem with images then we just ask someone to put images in release. [09:00] did that make sense? [09:00] bigjools: I just checked and it seems the 'release' images for Trusty are already there. [09:00] \o/ [09:00] JFDI then [09:01] * gmb -> getting breakfast; bbiab [09:01] Yep. [09:01] JFDoingI [09:01] o/ [09:03] rvba, jtv: https://code.launchpad.net/~allenap/maas/dhcp-leases-parsing/+merge/215112 is my work-in-progress for speeding up lease parsing. [09:04] It uses a regex to identify records, then it select only the latest ones, then it uses the full parser to break those apart. [09:04] It saves a lot of work when the leases file is large. [09:04] bigjools: btw, the upcoming (still waiting for the RT ticket to go through —hint, hint) api doc page has a toc: compare http://people.canonical.com/~rvb/maas-docs/api.html with http://maas.ubuntu.com/docs/api.html [09:05] allenap: that's very little code indeed... not sure what it does yet. [09:05] rvba: can you go and pester them again for the RT please [09:07] rvba: and the toc is a nice improvement, thanks [09:07] bigjools: we got a response on the RT, just no estimation of when it will be done. I'll ask them about that. [09:07] rvba: ok, thanks [09:08] Done. === vladk|offline is now known as vladk [10:12] rvba: did you want to make the change to how/where we import trusty? [10:13] If not, I can propose a quick branch. [10:23] jtv: I have a branch already. I'm testing a package built from it right now. [10:24] jtv: https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 WIP until I get confirmation that it's working as expected. [10:26] Why not just move the "trusty" selection under the other source? [10:26] I'm currently setting up for an import with that config btw. [10:28] jtv: yes, that would be even a bit simpler. Fixing the branch now. [10:31] Oh dear. Import fails while trying to write the meta file: snapshot directory does not exist! [10:32] I have a horrible feeling we haven't been getting any new dailies for a while, and so failed to notice some problem or other... [10:34] uh-oh [10:36] Just filed it as bug 1305758 [10:36] bug 1305758 in MAAS "Import fails while writing maas.meta: No such file or directory" [Critical,Triaged] https://launchpad.net/bugs/1305758 [10:46] Oh, another possibility I guess would be that there is simply nothing to download, and that this gets handled particularly badly in some cases. [10:46] jtv: the import doesn't seem to work now. I only got the precise image. [10:47] Any tracebacks? [10:47] No, no traceback. [10:47] Spooky. [10:48] Like you said, maybe there is nothing to download. Although the images seem to be there. [10:49] Probably identical to versions we already had... [10:49] And I don't see anything that would create that snapshot directory if there was nothing to download. [10:49] The code would try to write that maas.meta file, but the directory wouldn't exist. [10:49] I seem to remember that this was always a weakness in the code, actually. [10:50] jtv: the images seem to be there but clearly, the index file doesn't contain an entry for Trusty/release. [10:50] Maybe because the same file was already in there as Trusty/daily? [10:50] jtv: I guess I'll wait for smoser to come online and ask him about that. [10:51] Wow. Latest images I have in cache are from March 31. [10:53] Uh-oh. Deleting everything from /var/lib/boot-resources doesn't fix the problem either. [10:53] And it fails suspiciously quickly — within a second. [10:53] Maybe because it's hitting the caching proxy. [10:54] pdb time :) [10:56] When I put the daily trusty import back in (in addition to the release trusty) it seems to get going again. [10:57] But of course maybe it's just slower to fail because I made it download stuff. [10:57] I'm expecting to be called out soon. May not have time to say so. [11:13] jtv: when importing (with the updated config) from a freshly installed package, I don't get a traceback. [11:13] !? [11:13] Only precise gets imported. but no traceback. [11:13] Then I guess it may be getting confused because the same images are in different streams with different metadata... [11:14] Although then why did it keep failing for me when I deleted my cache & snapshots..? [11:14] I doubt that's the problem; like I said, there is no reference to Trusty/release in the index. [11:15] Oh, there still isn't? [11:15] Ah yes, see that. [11:15] No. Again: the images seem to be there but there is no reference to them in the index. [11:16] So then the import procedure wouldn't find them... I think. [11:16] That's the behavior I see. [11:16] Doesn't explain the bug you're seeing though. [11:20] But the behaviour you're getting sounds completely correct under the circumstances, so maybe it's just something weird in my setup. [11:20] After the ongoing import I'll try re-running it, and if that doesn't reproduce the problem, I'll try re-running but without the daily trusty source. [11:20] k [11:21] But like you said, this part of the code seems a bit fragile. I'd be relieved if we could get to the bottom of this. [11:23] That's exactly why I'm trying to reproduce the problem. [11:23] Can't promise that it'll work. :( [11:46] Ahhh, I've reproduced the traceback. [11:46] By commenting out the "daily" source. [11:47] Ah! Maybe I understand why! [11:47] The snapshot directory gets created, "en passant" as it were, when is downloaded from the simplestreams repo. Not sure what exactly, but no downloads means no snapshot directory. [11:47] But then. [11:48] (Good thing I recently refactored this code — otherwise I wouldn't have understood it) [11:48] Then, the import code generates a yaml dump for the metadata it has downloaded from the repo, _in memory_, and compares it to what's in /var/lib/maas/boot-resources/current/maas.meta [11:49] If the two do not match, then something has changed, and so the import code decides that the new snapshot directory is worth keeping. [11:49] It writes a new maas.meta file in that snapshot directory. [11:49] Which, oops, does not exist because all that happened is that things disappeared. [11:50] I think the sensible thing to do is to create the snapshot directory. Assuming the rest of the code behaves sensibly. === fader_ is now known as fader [12:00] Oh dear. The story just got weirder. [12:00] The metadata dict is empty. [12:01] That means that no matching products were found. [12:35] Bother. All this time wasted on what is probably a syntax error. I don't like yaml. [13:17] smoser: around? [13:20] jtv: gmb: allenap: is one of you taking care of https://code.launchpad.net/~andreserl/maas/third_party_drivers/+merge/215065 ? [13:21] Not me, sorry! [13:44] rvba: Yeah, I was looking at it, but I’m not going to be able to review it until at least 1900 UTC. [13:44] allenap: I've written the tests. [13:44] roaksoax: ^ is that going to be too late. [13:44] rvba: \o/ [13:44] allenap: I'm taking care of it unless gmb wants to review it :) [13:44] rvba: If gmb’s not around I think a selfie might be in order. [13:45] allenap: that's the plan [13:54] allenap: nope, we have until EOD today [13:55] allenap: i'll be pushing the release team toapprove this too while jhobbs finishes up some changes [13:55] allenap: all the hardcodede stuff (where the pPA is and stuff needs to go on a config file) [13:56] roaksoax: btw, we'd like to land https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 [13:56] But it seems the images for Trusty/release are not included in the index file yet. [13:56] The simplestreams index that is. [13:56] rvba: so it would fail? [13:56] rvba: maas-improt-pxe-files would fail? [13:57] roaksoax: it would not fail for it would only import precise's images. [13:57] s/for/but/ [13:57] rvba: so there's something weird [13:58] rvba: http://paste.ubuntu.com/7230893/ [13:58] rvba: and it that diff I see: arches: ["i386", "amd64"] [13:58] roaksoax: what's weird? [13:59] roaksoax: the config file gets rewritten… but it's semantically the same. [13:59] rvba: ok [14:01] rvba: so, i'm thikning that sicne there no release for trusty yet [14:01] rvba: we could sru this, or tryu to get it post today? [14:01] roaksoax: SRU works for me. It's a bit of a chicken and egg problem. [14:01] yeah [14:01] bigjools: see ;) ^ [14:03] rvba: https://code.launchpad.net/~andreserl/maas/third_party_drivers_1.5/+merge/215185 [14:04] roaksoax: approved (you can usually self-review simple backports) [14:07] rvba: thanks :) [14:08] rvba: it does nee dot be manually uploaed right? === matsubara_ is now known as matsubara [14:49] smoser: when are the Trusty/release images going to be available in the simplestreams index on http://maas.ubuntu.com/images/ephemeral-v2/releases/ ? i.e. should we land https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 as an SRU? [14:58] rvba: don't lanmd anything to 1.5 please [15:01] roaksoax: well, I'm not landing this unless the images are there, that's for sure. [15:01] rvba: thganks [15:12] Hey folks, is there any documentation anywhere on authenticating against the REST API? [15:12] I can use it properly from a web browser if I have logged into MAAS interactively already, but if I haven't logged in or try from a script I get something like "Unrecognised signature: GET list" [15:12] Seems to be similar to: http://askubuntu.com/questions/402691/handling-ubuntu-maas-restful-api-login (and not covered that I see in the API docs) [15:17] fader: Hi, I just posted a reply to that question on askubuntu.com. Although we know the documentation is a bit poor in this area, the example Python code should be you started. [15:17] fader: note that, if you're using Python, you can use the client library directly. [15:19] rvba: Thanks, I'll take a look! (Don't shoot me but I was planning to do it from PHP via its built-in URL grabbing as a prototype) [15:20] I'm just trying to build a page that shows the status of multiple MAAS clusters as a proof-of-concept, nothing that will really be in production [15:24] hi smoser, roaksoax, it looks like maas defaults to syncing the daily ephemerals as well as the release versions [15:24] is that the way we are going to release it? [15:25] tych0: That was my question to smoser :). We've got https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 ready to land. But we're waiting on simplestreams having the right data. [15:25] oh, i see [15:25] rvba: yeah, cool [15:27] rvba, ? [15:27] rvba: so one thing i don't understand about that diff, can we not specify two releases in the same keyring path? [15:28] oh. i see. [15:28] i'd land it. [15:28] tych0: that's exactly what that branch does. The diff is a bit messed up. [15:28] or maybe a question better for smoser [15:28] well you're not going to have something labeled release until ... after release. [15:28] rvba: ah, ok [15:28] rvba: i am not that good at reading diffs :-) [15:28] so that would put you in the realm of SRU [15:28] smoser: okay, so I guess we will SRU this [15:29] tych0: this diff is particularly nasty [15:29] :-) [15:29] suck. [15:29] alright. so lets figure something out here. [15:29] i'll try to get something itnto daily today. [15:29] tych0: here is the file http://paste.ubuntu.com/7231245/ [15:30] and we can test that, and then i think i'm willing to call somethinng release in this single case. [15:30] but we could also possibly call it "rc" or something [15:30] smoser: it's a bit of a chicken and egg problem. [15:30] and you allwo the label "rc" [15:30] label rc|release [15:31] smoser: that would work [15:31] rvba: cool, that's what i was thinking [15:31] i dont think its terrible either. and actually, since you have (poorly) only 'trusty' in that list, then its safe in the future. [15:31] i really dont like that you've only extended the number of places with hard coded release names though. [15:32] Not sure what you're talking about. [15:32] 'trusty' [15:32] you'll never see 'urban' (of 'urban unicorn') [15:33] when it would be better if you started pulling those things in (or at least allowed for that) when said unicorn was 'release' or 'rc' [15:33] maas should not have a database of ubuntu names. [15:33] thats what i'm complaining about. [15:33] I see. This is a long-standing bug. [15:33] yes. and this config file extended the number of places where naems are typed. [15:34] i will work today [15:34] and try to get daily updated. [15:34] This file replaces two other files with these names in it. So technically, it's one step into the right direction. [15:34] rvba, thats good. [15:34] *and* its user editable config [15:34] rather than source code [15:34] :) [15:35] i'll get daily updated today. and we'll get that tested and then will promote a trusty to 'rc' [15:35] and then you can land that patch tomorrow [15:35] See, there is your silver lining. [15:36] smoser: okay, please send an email to a maas ML when it's done. Julian will probably be able to test and land the change to bootresources.yaml === vladk is now known as vladk|offline === CyberJacob is now known as CyberJacob|Away