[06:14] <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:15] <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:16] <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> :)
[08:23] <jam> rvba: merge conflict on your ssl-skip-check branch
[08:24] <rvba> jam: right, I'm on it, thanks for pointing it out.
[09:05] <rbasak> filter(arch=['armhf/highbank', 'armhf/armadaxp'])
[09:06] <w7z> arch__in=
[09:06] <allenap> filter(arch__in=['armhf/highbank', 'armhf/armadaxp'])
[09:07] <rbasak> arch_filter('arm')
[09:07] <rbasak> return filter(arch__in=['armhf/highbank', 'armhf/armadaxp'])
[09:48] <mgz> bug 1062340
[09:48] <mgz> ...nobot
[09:48] <mgz> thanks bot.
[11:14] <jtv> Any reviewers available for a smallish code extraction?  https://code.launchpad.net/~jtv/maas/maascli-fake-config/+merge/128466
[11:39] <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:40] <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:42] <allenap> jam: Cool. Not as conquer-all as hoped, but it's some improvement.
[11:42] <mgz> request.data makes more sense
[11:44] <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:45] <mgz> should give a baseline for the quoting, I suspect with C extentions json shouldn't be too bad though
[11:46] <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.
[12:04] <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:05] <rvba> allenap: does it ring a bell?
[12:12] <jtv> Thanks for the review rvba
[12:13] <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:14] <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:15] <rvba> jtv: you're right, if I move ~/.maascli.db the tests pass.
[12:15] <jtv> :/
[12:16] <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:21] <rvba> jtv: I'll file a bug.
[12:21] <jtv> Thanks.
[12:39] <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:40] <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:44] <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:45] <allenap> or is it too late for that?
[13:23] <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:44] <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:47] <rbasak> thanks jam. I'll do that then
[13:58] <mgz> right, that test just wants adapting, should have left a comment in it to that effect
[14:15] <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] <rbasak> (please)
[14:16] <roaksoax> allenap too late i think if u want to rename the packages you need to rename upstream so
[14:17] <roaksoax> otherwise it makes no difference
[14:18] <allenap> roaksoax: Okay, I'll stay away from that for now then.
[14:19] <roaksoax> allenap im not saying is not possible thought but Daviey was gonna accept the upload to the archives today
[14:20] <roaksoax> im on holliday today
[14:20] <roaksoax> allenap you might wanna check with him
[14:20] <rvba> Have a nice holiday roaksoax ;)
[14:21] <allenap> roaksoax: Right, sorry, didn't mean to bother you then.
[14:22] <roaksoax> rvba thanks ;)
[14:23] <roaksoax> allenap lol no worries im gonna be around just trying to stay away from work
[14:23] <roaksoax> ;)
[14:28] <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:29] <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:30] <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:31] <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:32] <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:34] <matsubara> rbasak, ah ok. thanks for the pointer
[14:40] <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:41] <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:42] <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:43] <rbasak> allenap: ah
[14:43] <rbasak> allenap: thanks!
[14:49] <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:54] <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:55] <jtv> Rings a bell.
[14:56] <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:57] <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:58] <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:59] <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.
[15:00] <jtv> Thanks.
[15:00] <jtv> I'll shove some food into my face.
[15:00] <mgz> rbasak: ace, will have a look
[15:03] <mgz> gah, something weird is going on
[15:03] <mgz> I'll throw away the instance I think
[15:10] <jam> mgz: any luck with the search string is juju constraints?
[15:11] <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:16] <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:17] <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:28] <mgz> ...some how my db is hosed in a way rming and destroying the vm does not fix...
[15:35] <mgz> hm, trunk is fine, rebase and hope time
[15:37] <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:38] <jtv> Thanks for the reviews allenap!
[15:38] <allenap> Welcome.
[15:39] <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:40] <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:41] <mgz> or not, because of django settings... >_<
[15:43] <jtv> I'll bet the problem goes away when you run your tests in isolation.
[15:43] <mgz> gah, no -1 option? noooose...
[15:44] <jtv> Man, using 4 kinds of pepper in one meal is awesome.  Two kinds as spices, two as vegetables.
[15:45] <mgz> okay, so I have an import error in a different bit of the tree
[15:46] <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:47] <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:49] <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.
[16:21] <mgz> okay, I'm all proposed up.
[16:28] <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:32] <mgz> rbasak: just done, with some minor comments
[16:32] <mgz> getting it in the daily sounds good.
[16:33] <rbasak> mgz: thanks, I'll get those changes done
[16:33] <jtv> allenap: let me have a look
[16:34] <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:36] <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:37] <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:38] <allenap> jtv: What did you do to make it update by the way?
[16:39] <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:40] <allenap> jtv: Haha :)
[16:40] <jtv> OCD-R-Us
[16:41] <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:42] <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:50] <rvba> jtv: I'm having a look at the comment Gavin made on your maascli-cli-subcommand branch…
[16:51] <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:52] <rvba> jtv: So, I don't really get why you're introducing this new subcommand.
[16:53] <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:54] <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:55] <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:56] <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:57] <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:59] <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.
[17:00] <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:01] <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:02] <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:03] <rvba> flacoste: roaksoax I /think/ this has been landed.
[17:03] <rvba> Let me check.
[17:03] <rvba> flacoste: roaksoax: confirmed, https://code.launchpad.net/~allenap/maas/anon-power-setting/+merge/128127 has landed.
[17:05] <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:06] <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:07] <roaksoax> Daviey: until when can we make uploads?
[17:07] <roaksoax> to archive
[17:08] <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:09] <flacoste> roaksoax: tomorrow 21UTC according to the ReleaseSchedule wiki page iuc
[17:10] <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:11] <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:12] <roaksoax> flacoste: ok, right, so since new upstreams are mostly bug fixes, then we should be good
[17:18] <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:19] <jtv> So it was Apache after all?
[17:19] <Daviey> roaksoax: Final Freeze kicks in tomorrow
[17:20] <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:21] <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:22] <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:25] <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:26] <roaksoax> Daviey: today's trunk on today's upload?
[17:27] <rvba> Daviey: roaksoax don't you think it's pointless to make an upload before we fix: bug 1063857 ?
[17:28] <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:29] <roaksoax> rbasak: i take that the branch you proposed for bug #1062340 takes care the i386 amd64 cases too?
[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:30] <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:31] <rbasak> roaksoax: I believe so, yes
[17:32] <roaksoax> cool
[17:34] <rvba> jtv: I just posted a reply to your review on https://code.launchpad.net/~rvb/maas/bug-1062607/+merge/128543
[17:40] <jtv> coming
[17:46] <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:54] <rvba> jtv: that's funny, my window manager disappeared a few hours ago :)
[17:57] <jtv> Question is: who has them?
[18:00] <roaksoax> rvba: around?
[18:00] <roaksoax> rvba: can you test the package i just uploaded to experimental
[18:00] <rvba> roaksoax: sure
[18:11] <rvba> roaksoax: the problem is still there :/ http://paste.ubuntu.com/1267881/
[18:12] <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:13] <rvba> Yeah, now /etc/maas/maas_cluster.conf is populated…
[18:15] <rvba> roaksoax: but now I don't see the cluster worker… even if I restart maas-cluster-celery.
[18:16] <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:18] <roaksoax> rvba: did you deploy on a new cloud instance?
[18:18] <rvba> roaksoax: yes
[18:20] <rvba> roaksoax: rarg, my fault, I made a mistake when I entered the url :/
[18:21] <rvba> roaksoax: Now it's fine
[18:22] <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:25] <roaksoax> rvba: i know what it is
[18:25] <rvba> ?
[18:26] <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:36] <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:37] <rvba> roaksoax: can we control the order in which the packages are installed?
[18:38] <roaksoax> rvba: not really no
[18:41] <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:44] <rvba> roaksoax: but that would mean having one package change the config of another one right?  Isn't it against the rules?
[18:47] <roaksoax> rvba: it is indeed., tjhat
[18:47] <roaksoax> that's where i was going next
[18:50] <roaksoax> Daviey: uploading now
[18:58] <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?
[19:05] <jtv> (I think gzip will do the right thing anyway if I try to compress an already-compressed file anyway)
[19:17] <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:45] <roaksoax> rvba wheres that
[19:45] <roaksoax> jtv: id you see the comment i made to your pscksging MP¿
[20:30] <Daviey> roaksoax: erm, this indicates 3 different uploads?
[20:30] <Daviey> can you fold debian/changelog to be accurate for the ubuntu archive?
[20:31] <roaksoax> Daviey it is just one upload
[20:32] <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:33] <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:34] <roaksoax> Daviey: my fault for not telling him earlier that changelog entreies were for releases in quantla not in PPA :)
[20:36] <Daviey> roaksoax: don't try to cover for him.. :D
[20:37] <roaksoax> oh well, i should have been clearer though
[20:39] <Daviey> heh
[20:40] <roaksoax> Daviey: do you want me to fix it though?
[20:40] <roaksoax> and merge all of the changelogs?
[20:45] <Daviey> roaksoax: Up to you.. Personally, i'd prefer it.. as it is currently a lie, but not enough to reject
[20:51] <roaksoax> Daviey: alright fixing it then
[20:56] <roaksoax> Daviey: i'm ready to upload
[20:58] <roaksoax> Daviey: could you please reject the other one?
[21:03] <Daviey> ok
[21:04] <roaksoax> Daviey: ok, new version uploaded it's all yours :)
[23:17] <bigjools> morning
[23:32] <bigjools> roaksoax: around?
[23:34] <roaksoax> bigjools: barely.. in class.. what's up?
[23:35] <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:37] <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:38] <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:39] <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:40] <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:42] <roaksoax> bigjools: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/121 http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/120
[23:45] <bigjools> ok
[23:46] <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:50] <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:54] <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:55] <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:56] <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:57] <bigjools> is that ok? makes sense?