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