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