[06:14] jam: thanks for the review - not sure what difference your suggestion makes as everything seems to work anyway. I think it's more a UI validation thing isn't it? [06:15] bigjools: I think if you get a form with multiple errors, the 'dict' method allows it to present both to users. [06:15] I could be 100% wrong, though. [06:15] I was just following along what other things did when I wrote a form recently. [06:15] heh, I honestly have no idea. Given this was an API call I figured a human readable string would be for the best but.... [06:16] bigjools: so the big win is to just not traceback, the rest is gravy [06:16] If it works for you, that's enough for me for now. [06:16] righto, cheers [06:16] I'm certainly not blocking the fix, just something I thought I saw. [06:16] well I am always open to improvements, otherwise what's the point of reviews [06:16] :) === jelmer is now known as Guest86701 [08:23] rvba: merge conflict on your ssl-skip-check branch [08:24] jam: right, I'm on it, thanks for pointing it out. [09:05] filter(arch=['armhf/highbank', 'armhf/armadaxp']) [09:06] arch__in= [09:06] filter(arch__in=['armhf/highbank', 'armhf/armadaxp']) [09:07] arch_filter('arm') [09:07] return filter(arch__in=['armhf/highbank', 'armhf/armadaxp']) === jelmer is now known as Guest5727 [09:48] bug 1062340 [09:48] ...nobot [09:48] Launchpad bug 1062340 in MAAS "juju provider interacts poorly with arch constraints" [High,In progress] https://launchpad.net/bugs/1062340 [09:48] thanks bot. [11:14] Any reviewers available for a smallish code extraction? https://code.launchpad.net/~jtv/maas/maascli-fake-config/+merge/128466 [11:39] allenap: so after looking into it, it appears you *can* send application/json (or yaml, or a few things), but it doesn't come through transparetly. [11:39] Instead of coming in as request.POST or request.GET, you get it as request.data [11:40] (unless POST and GET also set data?) [11:40] allenap: and performance wise, 42s with encode_multipart_data, and 33s as JSON with my hacks [11:42] jam: Cool. Not as conquer-all as hoped, but it's some improvement. [11:42] request.data makes more sense [11:44] mgz: well, clearly I broke something as trying to revert to non JSON completed in 5s :) (with nothing getting updated, so clearly broken) [11:44] if you hack it to just concat the raw output and return in as application/octet-stream, what's the timing on that? [11:45] should give a baseline for the quoting, I suspect with C extentions json shouldn't be too bad though [11:46] mgz: well, I'd still need to parse it, since we're dealing in batches. [11:46] (or is timing just that side difficult?) [11:46] mgz: I can run it under lsprof to get feelings for timing as well. For 'how much time is spent in this C extension' lsprof is quite good [11:46] because it doesn't hook the extension and slow it down. [12:04] allenap: I was just running the test suite in your branch 'make-docutils-happy' and I noticed a test failure that is also there in trunk (!): http://paste.ubuntu.com/1267323/ [12:05] allenap: does it ring a bell? [12:12] Thanks for the review rvba [12:13] rvba: tests are passing for me... I hope I didn't accidentally land a bad maascli change. [12:13] Actually, I just ran tests in trunk and they passed... [12:13] jtv: really? That's weird… [12:14] Ah! The test may be affected by the existence of maascli profiles. [12:14] Annoying global state. [12:14] That branch I have up for review will make it easier to patch that part. [12:15] jtv: you're right, if I move ~/.maascli.db the tests pass. [12:15] :/ [12:16] rvba: if you move it back and run those same command lines that fail in the test, you may get a slightly more informative error. [12:16] Probably not very, since maascli swallows tracebacks, but some. [12:21] jtv: I'll file a bug. [12:21] Thanks. [12:39] if I do request.GET.get("something") what happens if non-ascii bytes are percent encoded in the query string value? [12:39] arbitrary bytestring? decoded to unicode as utf-8? left quoted? [12:40] jtv, rvba: Slighty related, but I may change the -d/--debug flag to be on the root argument parser, then we can consult it about displaying stack traces. [12:40] allenap: I'm about to move the parser into its own module. [12:40] jtv: Okay, I'll stay away from it for now. [12:40] I was having the same thought, actually. [12:44] Haha :) [12:44] roaksoax: Hi there. How do you feel about some package renames, a la https://bugs.launchpad.net/maas/+bug/1053507 [12:44] Ubuntu bug 1053507 in MAAS "maas installs python modules with out any namespacing" [Critical,Triaged] [12:45] or is it too late for that? === fjlacoste is now known as flacoste [13:23] mgz: I think I've got all the pieces, but what do I do about the test_POST_acquire_treats_unknown_arch_as_resource_conflict test? Now that I'm raising InvalidConstraint for an unknown architecture, the API returns an HTTP 400. Shall I just change the test accordingly, or is there some other behaviour that we want/ [13:23] ? [13:44] rbasak: I think BAD_REQUEST is better than CONFLICT [13:44] it just did conflict because that is what it was doing. [13:47] thanks jam. I'll do that then [13:58] right, that test just wants adapting, should have left a comment in it to that effect [14:15] smoser: do we have a precise ephemeral image released with a fix for bug 978127 yet, and if not, what's the schedule for this? [14:15] Launchpad bug 978127 in cloud-init (Ubuntu Precise) "incorrect time on node causes failed oauth" [High,Triaged] https://launchpad.net/bugs/978127 [14:15] (please) [14:16] allenap too late i think if u want to rename the packages you need to rename upstream so [14:17] otherwise it makes no difference [14:18] roaksoax: Okay, I'll stay away from that for now then. [14:19] allenap im not saying is not possible thought but Daviey was gonna accept the upload to the archives today [14:20] im on holliday today [14:20] allenap you might wanna check with him [14:20] Have a nice holiday roaksoax ;) [14:21] roaksoax: Right, sorry, didn't mean to bother you then. [14:22] rvba thanks ;) [14:23] allenap lol no worries im gonna be around just trying to stay away from work [14:23] ;) [14:28] rbasak, you want to test the daily there? [14:28] i can then promote that. [14:28] matsubara: ^^ could you try the daily ephemeral on highbank please? [14:29] rbasak, yes, will do today. I saw your email and the only workaround I didn't know how to do was to adjust the RTC for the arm board [14:30] matsubara: yeah it's really awkward, since MAAS is the preferred tool to get an Ubuntu install on highbank in the first place [14:30] matsubara: I think that if the daily does fix it then trying the daily will be the least work for all of us to verify it [14:31] rbasak, cool [14:31] matsubara: to verify that you have the problem, check the apache logs on the MAAS server. I think /var/log/apache2/access.log or something? [14:32] matsubara: if you see a load of 40(1? 3?) messages for the same URL within a minute or two of booting into commissioning, then you have the RTC issue [14:34] rbasak, ah ok. thanks for the pointer [14:40] rbasak, the other thing we need to hvae qa'd is at least that they do not regress 12.04 [14:40] the 12.04 maas. [14:41] so if you wanted to walk http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-precise.txt to make sure we get those done, that'd be great. [14:41] allenap: could you take a look at the test noise in http://paste.ubuntu.com/1267509/ please? The diff I'm working on is http://paste.ubuntu.com/1267475/. I can't see what I'm doing to introduce this, and the noise is particularly unhelpful. [14:41] i'm not here today. [14:42] rbasak: That's fixed in trunk. [14:42] Ignore it for now. [14:42] allenap: how long ago? I pulled trunk an hour or so ago. [14:42] rvba: r1217 [14:43] allenap: ah [14:43] allenap: thanks! [14:49] Any reviewers available? I have some MPs waiting: https://code.launchpad.net/~jtv/maas/maascli-extract-parser/+merge/128501 and https://code.launchpad.net/~jtv/maas/maascli-profile-module/+merge/128510 [14:54] allenap, can I prevail on you perhaps? [14:54] Or is "impose" the word I'm looking for? [14:54] does this error trying to run tests after pulling changes from today mean anything to anyone? [14:55] Rings a bell. [14:56] Try "make distclean" and then "rm -rf db" [14:56] Then try again. [14:56] make clean and rm -rf db didn't help [14:56] I'll try distclean. [14:56] Best do the distclean first; it kills the postgres instances running inside your branch. [14:57] hm, and eggs, I might back them up first [14:57] back them up? [14:57] The db directory in your branch was designed to be utterly disposable. [14:58] I haven't bothered setting up an egg cache here, as I'm only using one working tree [14:58] Ah [14:58] getting everything from pypi again would be mildly annoying [14:58] Well you _can_ just kill postgres instances and rm -rf db. [14:58] If that didn't fix this problem, I don't think "make distclean" would. [14:58] mgz: https://code.launchpad.net/~racb/maas/arch-constraint-wildcard/+merge/128513 [14:59] Ohhhh this wasn't the weird problem involving transactional tests, was it? [14:59] mgz: tests pass. I haven't tried a juju bootstrap yet though. I'll need to create a package and test from that, which will take a while [14:59] jtv: Sure, I'll take a look. [15:00] Thanks. [15:00] I'll shove some food into my face. [15:00] rbasak: ace, will have a look [15:03] gah, something weird is going on [15:03] I'll throw away the instance I think [15:10] mgz: any luck with the search string is juju constraints? [15:11] jelmer: any luck with the retry code? [15:11] rbasak: looks good [15:11] After those things, the next important thing is to do pagination on the 'nodes' listings. [15:11] jam: I'm done, am just trying to get the test suite to actually run... [15:16] mgz, allenap, jelmer: I'm trying to tune the 'batch_size' for tag processing. Bumping it from 100 to 1000 means downloading 25MB per batch (for the XML) vs 2.5MB for the batch. [15:16] And speeds up the 12,000 unit case from 37s to 35s. [15:17] ....that doesn't seem much [15:17] Trying to bump it to 10,000 increases the batch size to 250MB, which crashes on my 2GB VM [15:17] ehehe [15:17] (I'm guessing there are multiple levels so that at peak we have >1 copy of the full text) [15:17] json.loads() isn't streaming, etc. [15:28] ...some how my db is hosed in a way rming and destroying the vm does not fix... [15:35] hm, trunk is fine, rebase and hope time [15:37] mgz: we have observed some problems that seem to be affected by interactions between tests, and maybe test setup/teardown. Did you add or remove any test cases? [15:38] Thanks for the reviews allenap! [15:38] Welcome. [15:39] jtv: yes, new test class, and nose stopped admitting to the existence of the whole module [15:39] (generally means something inside the module is raising ImportError, but I can't spot it) [15:40] mgz: then I'd look in that direction for suspects. Still a mystery why this happens. Does your test case do anything weird? Like rely on transactions behaving realistically, or models that exist only within the tests? [15:40] bin/py -c "import maasserver.tests.test_views_nodes" should tell me that much... [15:41] or not, because of django settings... >_< [15:43] I'll bet the problem goes away when you run your tests in isolation. [15:43] gah, no -1 option? noooose... [15:44] Man, using 4 kinds of pepper in one meal is awesome. Two kinds as spices, two as vegetables. [15:45] okay, so I have an import error in a different bit of the tree [15:46] Is it a circular import or something like that? [15:46] typoed 'node' as 'name' from models when importing into views [15:46] so, shouldn't be circular (models don't care about views) [15:47] but is related to the test module that was misbehaving [15:47] ...implies some cleanup on db level isn't happening if test fails at too early a stage? [15:47] starts db setup, tries to setup tests, gets error, cleanup doesn't run, or similar? [15:49] We are completely in the dark. Otherwise we'd probably have fixed it by now! [15:49] Note how incredibly early it happens. [16:21] okay, I'm all proposed up. [16:28] mgz: may I have a +1 for https://code.launchpad.net/~racb/maas/arch-constraint-wildcard/+merge/128513 or do you not think it OK to land yet? I'm thinking that if I get it in the daily then we can easily test tomorrow - otherwise I'm tight for time for today's EOD anyway [16:28] jtv: Did you forget a prerequisite branch, or is the diff wrong on https://code.launchpad.net/~jtv/maas/maascli-cli-subcommand/+merge/128538? [16:32] rbasak: just done, with some minor comments [16:32] getting it in the daily sounds good. [16:33] mgz: thanks, I'll get those changes done [16:33] allenap: let me have a look [16:34] allenap: I jumped the gun on that one and assumed the diff would update. I'll see if I can trigger a re-diff. [16:36] jtv: Don't worry about it too much; I have generated it for myself. [16:36] rbasak: one option I didn't mention was you could avoid the aliased_value stuff by doing that in the same mapping too [16:36] allenap: too late :) [16:36] ie, `architecture_wildcards['arm'] = architecture_wildcards['armhf']` [16:37] or equivalent. [16:37] mgz: that's very tidy - thanks! [16:37] moving as much of that logic out of the constrain_architecture function and into precalculated data I like [16:38] jtv: What did you do to make it update by the way? [16:39] allenap: I replaced some instances of "log-in" and "log-out" (used as verbs) with "log in" and "log out" in the api.py docstrings. [16:40] jtv: Haha :) [16:40] OCD-R-Us [16:41] rvba: Would you be able to give a second opinion on https://code.launchpad.net/~jtv/maas/maascli-cli-subcommand/+merge/128538? [16:41] * allenap has to go, urgently, to collect kids. [16:42] allenap: sure. [16:42] allenap: could you have a look at the branch I just put up for review when you get back: https://code.launchpad.net/~rvb/maas/bug-1062607/+merge/128543 [16:50] jtv: I'm having a look at the comment Gavin made on your maascli-cli-subcommand branch… [16:51] jtv: but the 'cli' subcommand is long gone am I right? [16:51] No, it's brand new. [16:51] arg, I mean s/cli/api/ [16:52] jtv: So, I don't really get why you're introducing this new subcommand. [16:53] The api subcommand is long gone, but the next step is to remove the profile name as a subcommand. [16:53] Did I say "api"? Mistake. [16:53] Right now you'd say something like "maascli mylogin acquire_node " [16:53] Indeed. [16:54] and that should become, for the case where mylogin is the default profile: [16:54] "maascli acquire_node " [16:54] Right, I get that… what does it have to do with 'api' or 'cli' then? [16:55] I'm just trying to understand what Gavin said in his comment. [16:55] If we _also_ have commands like "maascli login profile URL", then they live in the same namespace as the methods of the API. [16:55] Not a good idea: "list" could easily be used in both the CLI commands and the API, for instance. [16:56] So the CLI commands (login, logout, refresh, list) move into a separate subcommand. [16:56] That leaves the root namespace free for API commands. [16:56] Ah ok, I see. [16:57] I wasn't aware of the intention to move the CLI commands under 'cli'. [16:57] rvba: weird, you run into that db_ bug [16:59] rvba: sorry -- I've been trying to mention the big picture in all my MPs but it's hard not to start skipping things with so much repetition. [17:00] jtv: I understand. But I've been asked to give a second opinion so I needed to put all the pieces of the puzzle together. :) [17:00] I hope that doesn't mean trouble for my branch! [17:00] It's a bit of a difficult transition, trying to do everything in small chunks. [17:00] I imagine :) [17:01] roaksoax: has ipmi setting in enlistment landed? [17:01] I think Gavin is right though. I'll summarize my thoughts on the MP. [17:01] flacoste: not as of friday... today I didn't check (i'm not really here, US holidays...) [17:02] roaksoax: aren't you the one working on that? [17:02] flacoste: allenap was the one who was working on enabling the power settings for enlistment [17:03] flacoste: roaksoax I /think/ this has been landed. [17:03] Let me check. === flacoste changed the topic of #maas to: Final Freeze is tomorrow| Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ [17:03] flacoste: roaksoax: confirmed, https://code.launchpad.net/~allenap/maas/anon-power-setting/+merge/128127 has landed. [17:05] flacoste: landed today so tomorrow I'll take care of the enlistment IPMI temporary credentials then [17:05] roaksoax: ok, and we'll 0-day SRU any hiccups from that? [17:06] flacoste: yeah [17:06] landing this tomorrow seems very risky since we won't have time to react to any problem [17:06] nor have matsubara do a proper round of QA around the new changes [17:07] Daviey: until when can we make uploads? [17:07] to archive [17:08] flacoste: right, so landing this will only make use of the script that does the detection during the commissioning, but does need support from maas-enlist [17:09] roaksoax: tomorrow 21UTC according to the ReleaseSchedule wiki page iuc [17:10] flacoste: right, so i'm wondering now, what's the latest upstream release that we are going to actually release to archives? [17:10] flacoste: i made an upload over the weekend that Daviey will process [17:10] flacoste: but I'm updating that (same upstream release though) with packaging fixes [17:11] roaksoax: there have a couple of bug fixes in progress that should be released [17:11] roaksoax: so we should plan on a new upstream tomorrow [17:12] flacoste: ok, right, so since new upstreams are mostly bug fixes, then we should be good [17:18] jtv: do you have time to review https://code.launchpad.net/~rvb/maas/bug-1062607/+merge/128543 ? [17:18] I think I can, yes [17:18] Thanks a lot. [17:19] So it was Apache after all? [17:19] roaksoax: Final Freeze kicks in tomorrow [17:20] And this large upload certainly needs to be in by then [17:20] After that, we can sneak in some last minute fixes. [17:20] Daviey: right, which means with the latests upstream release [17:20] right [17:20] jtv: yes [17:21] Daviey: ok so instead of uploading today, I guess I'll make an upload tomorrow [17:21] Daviey: and the enlistment stuff... takes more than just add the support to MAAS [17:22] Daviey: cause needs work on maas-enlist as well [17:22] rvba: https://code.launchpad.net/~andreserl/maas/packaging_updates_bzr1099-2/+merge/128551 [17:22] please: ) [17:25] roaksoax: erm, getting trunk onto tomorows ISO i would consider vital [17:25] so an upload today and another tomorrow [17:25] Daviey: alright! [17:26] Daviey: today's trunk on today's upload? [17:27] Daviey: roaksoax don't you think it's pointless to make an upload before we fix: bug 1063857 ? [17:27] Launchpad bug 1063857 in maas (Ubuntu) "Cluster controller fails to start because MAAS_URL is not set." [Critical,Triaged] https://launchpad.net/bugs/1063857 [17:28] rvba: that's fixed already [17:28] rvba: see above link i sent you :) [17:28] roaksoax: it that fixing it? Ok then :) [17:29] rbasak: i take that the branch you proposed for bug #1062340 takes care the i386 amd64 cases too? [17:29] Launchpad bug 1062340 in MAAS "juju provider interacts poorly with arch constraints" [High,In progress] https://launchpad.net/bugs/1062340 [17:29] rvba: TBH, we keep saying that.. and the upload is embarrassingly large already [17:29] heck, it still uses ipmitool [17:29] roaksoax: I believe so. Could you clarify exactly what you mean? That "amd64" should work? [17:30] rbasak: i mean, it completely replaces my branch and if juju sends amd64 it gets mapped correctly and won't fail to acquire node? [17:31] roaksoax: I believe so, yes [17:32] cool [17:34] jtv: I just posted a reply to your review on https://code.launchpad.net/~rvb/maas/bug-1062607/+merge/128543 [17:40] coming [17:46] Replied. I'll do a bit of rebooting to see if that'll bring back my window manager. I've been working without one since before midnight. [17:54] jtv: that's funny, my window manager disappeared a few hours ago :) [17:57] Question is: who has them? [18:00] rvba: around? [18:00] rvba: can you test the package i just uploaded to experimental [18:00] roaksoax: sure [18:11] roaksoax: the problem is still there :/ http://paste.ubuntu.com/1267881/ [18:12] rvba: sudo dpkg-reconfigure maas-cluster-controller ? [18:12] MAAS_URL=http://192.168.2.110/MAAS [18:12] that;s me [18:13] Yeah, now /etc/maas/maas_cluster.conf is populated… [18:15] roaksoax: but now I don't see the cluster worker… even if I restart maas-cluster-celery. [18:16] rvba: weird, I have arunning cluster [18:16] roaksoax: can you pastebin 'ps aux | grep celery' ? [18:16] ubuntu@node2:~$ sudo service maas-cluster-celery status [18:16] maas-cluster-celery start/running, process 8009 [18:16] https://pastebin.canonical.com/76065/ [18:16] err [18:18] rvba: did you deploy on a new cloud instance? [18:18] roaksoax: yes [18:20] roaksoax: rarg, my fault, I made a mistake when I entered the url :/ [18:21] roaksoax: Now it's fine [18:22] rvba: right, but initial autodetection is not working [18:22] roaksoax: indeed. [18:22] rvba: idk what bigjools might have changed [18:22] if any [18:25] rvba: i know what it is [18:25] ? [18:26] rvba: it doesn't ask for the dbconfig question if it couldn't be autodetected [18:26] rvba: but then it replaces it from loclhost to nothing [18:36] rvba: https://code.launchpad.net/~andreserl/maas/packaging_update_cluster/+merge/128564 [18:36] now it will be left as localhost/MAAS [18:36] rvba: the problme is that maas-region-controller installs after maas-cluster-controller, causing that the latter cannot autodetect the URL [18:37] roaksoax: can we control the order in which the packages are installed? [18:38] rvba: not really no [18:41] roaksoax: I've approved the branch. [18:41] rvba: what could be done for such case is allow the region-controller set that value [18:44] roaksoax: but that would mean having one package change the config of another one right? Isn't it against the rules? [18:47] rvba: it is indeed., tjhat [18:47] that's where i was going next [18:50] Daviey: uploading now [18:58] smoser: having a look at bug 1050033... the old Precise version of maas-import-ephemerals has installed initrd files. There is no .gz suffix, but I think they were already gzip-compressed. Is that normal? Can I assume that an initrd file will already be gzipped, so that I can just link or rename? [18:58] Launchpad bug 1050033 in MAAS "maas-import-pxe-files has copying errors after package upgrade" [Critical,Triaged] https://launchpad.net/bugs/1050033 [19:05] (I think gzip will do the right thing anyway if I try to compress an already-compressed file anyway) [19:17] roaksoax: is that normal that debian/changelog contains "maas (0.1+bzr1223+dfsg-0ubuntu1~ppa1) quantal; urgency=low"… I mean the 'ppa' part? [19:45] rvba wheres that [19:45] jtv: id you see the comment i made to your pscksging MP¿ [20:30] roaksoax: erm, this indicates 3 different uploads? [20:30] can you fold debian/changelog to be accurate for the ubuntu archive? [20:31] Daviey it is just one upload [20:32] roaksoax: the changelog shows 0.1+bzr1223+dfsg-0ubuntu1, 0.1+bzr1110+dfsg-0ubuntu1, 0.1+bzr1063+dfsg-0ubuntu1, [20:32] two of them were never uploaded to quantal? [20:33] Daviey: yeah I know what's wrong [20:33] PPA vs Archive changelog? [20:33] Daviey: yeah, bigjools made uploades and treated as releases in the packaging branch [20:33] uploads to PPA [20:33] ahh [20:33] blame bigjools then :) [20:34] Daviey: my fault for not telling him earlier that changelog entreies were for releases in quantla not in PPA :) [20:36] roaksoax: don't try to cover for him.. :D [20:37] oh well, i should have been clearer though [20:39] heh [20:40] Daviey: do you want me to fix it though? [20:40] and merge all of the changelogs? [20:45] roaksoax: Up to you.. Personally, i'd prefer it.. as it is currently a lie, but not enough to reject [20:51] Daviey: alright fixing it then [20:56] Daviey: i'm ready to upload [20:58] Daviey: could you please reject the other one? [21:03] ok [21:04] Daviey: ok, new version uploaded it's all yours :) [23:17] morning [23:32] roaksoax: around? [23:34] bigjools: barely.. in class.. what's up? [23:35] roaksoax: just wanted to check in with you and see how things are going [23:35] bigjools: maas is in quantal... tomorrow we'll be making a new upload :) [23:35] roaksoax: did anyone test upgrades from precise? [23:37] bigjools: not from the new packages (there's no way to do it as it disables PPA's). That's something that has to be done now [23:38] there's always a way ;) [23:38] ok, I guess I'll be firing up some canonistack instances today [23:38] bigjools: i tested from precise -> older quantal -> newer quantal so I'm pretty confidence it will wokr [23:38] bigjools: and yes I was planning to do the same after I come back home [23:38] cool [23:39] I will look at some things I know we had to hack hard on to make work for upgrades [23:39] bigjools: the cluster things will still be a problem [23:39] in what way [23:39] ? [23:40] bigjools: the question is not being asked being medium priority [23:40] rvba reported that today and I fixed a couple bugs there [23:42] bigjools: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/121 http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/120 [23:45] ok [23:46] bigjools: the problme is that in some cases it seems that it gets installed before maas-region, hence it fails [23:46] bigjools: i think however, that in the installer i could override that questions [23:46] that question [23:50] roaksoax: hmmm the config file should be on disk from the existing maas package though [23:50] hence no question should ever be asked [23:54] bigjools: right, but it was resulting on the maas_cluster.conf having URL= [23:54] that can only mean that the existing config was broken then [23:54] oh this is the db_get cockup [23:55] bigjools: yeah, so db_get was returning empty [23:55] so, the question should still not get asked [23:55] and that logic was fixed I see, so... where's the problem? :) [23:55] bigjools: that the question should be asked on machines that do not have the region-controller [23:56] roaksoax: that is perfectly fine [23:56] the package is never auto installed [23:56] alright [23:56] only on upgrades from maas [23:56] where the config is guaranteed to exist [23:56] alright [23:57] is that ok? makes sense?