[00:00] Conn was an artifact of the old days when agents used to connect directly to mongo [00:00] perrito666: what's trhe use case, is this for restore? [00:00] wallyworld: yup, same part, new restore [00:01] perrito666: do you need state or apiState? [00:01] there's NewAPIState to get you an api connection [00:01] that takes an environment [00:02] I was using conn.State [00:07] https://github.com/juju/names/pull/18 <-- ActionResultTag added to complement the exisiting ActionTag in the names package [00:18] menn0: tmpfs /tmp tmpfs nodev,nosuid,mode=1777 0 0 [00:18] ^ put that in /etc/fstab [00:19] perrito666: conn.State was just made from a call to state.Open(), using info extracted from the environment [00:20] if you really did need access to state.State rather than api.State, you could add a helper method to state/open.go [00:20] jcw4: done with review [00:28] OOPS: 139 passed, 114 FAILED, 4 PANICKED, 5 MISSED [00:28] --- FAIL: TestPackage (264.62s) [00:28] god damnit [00:33] fwereade: https://github.com/juju/juju/pull/353 [00:35] tasdomas: https://github.com/juju/juju/pull/354 [00:43] davecheney: thanks! [00:52] davecheney: I addressed the issues you commented on; I'm stepping away for the evening but if you get a chance to respond that will be appreciated [00:52] Cheers! [01:45] wallyworld: the core work for #1271144 was done in 1.17.6, so it's already in 1.20 [01:45] <_mup_> Bug #1271144: br0 not brought up by cloud-init script with MAAS provider

[01:45] just need to do the other one I think [01:45] #1337091 [01:45] <_mup_> Bug #1337091: maas provider: allow users to specify network bridge interface.

[01:46] axw: great, ok [01:49] ah, I think I added that didn't I. doh [01:49] removing it from the milestone [01:51] apiclient_test.go:127: c.Assert(err, gc.ErrorMatches, `unable to connect to "wss://.*/"`) [01:52] ... error string = "unable to connect to \"wss://127.0.0.1:42509/environment/6e4a12fc-b1c1-4fc7-8401-6cb66fce31b2/api\"" [01:52] ... regex string = "unable to connect to \"wss://.*/\"" [01:52] [LOG] 0:00.249 INFO juju.provider.dummy reset environment [01:52] oh [01:52] how is this a failure ?!? [01:52] i see [02:01] thumper: waigani https://github.com/juju/juju/pull/356 [02:10] wallyworld: what else would you like me to do for 1.20.2? [02:15] axw: i'm still working through the i/o timeout issues getting passing tests. like hitting gophers :-( perhaps take a peek at the ec2 health failures to see if there's anything we can do. might just be an ec2 issue but i'm not sure [02:15] wallyworld: cool, that's what I started doing. [02:15] great :-) [02:15] wss://127.0.0.1:42509/ [02:15] but not wss://127.0.0.1:42509/api [02:15] and not wss://127.0.0.1:42509/environment/xxxx/api [02:24] axw: also, we've been told to reduce the max oplog file size from 50GB. I'm thinking 10GB might be reasonable [02:31] wallyworld: I think it could be lower, and concur with jam that we ought to do a size-to-capacity analysis [02:32] not sure how to go about that tho [02:33] yeah, me either [02:34] fwereade is -1 on reducing the size from the manufacturer's recommnedation so 10GB is sort of a compromise [02:34] wallyworld, I'm -0.5 at most, it's really just "let's analyse this, not just pull a number out of our collective ass" [02:35] yeah, need to figure out ow to do that [02:36] we can adjust the size later if needed [02:36] if we make a wrong decision now [02:36] wallyworld: the problem is that changing existing installations is difficult [02:37] not impossible though [02:37] we can do it as an upgrade step can't we? [02:38] wallyworld: probably. not sure how current/correct this is, but: http://www.kchodorow.com/blog/2011/02/22/resizing-your-oplog/ [02:38] http://docs.mongodb.org/v2.2/tutorial/change-oplog-size/ [02:40] axw: i was looking at a more recent version, but yeah, it does involve some steps http://docs.mongodb.org/manual/tutorial/change-oplog-size/ [02:43] wallyworld, can you remember what the launchpad project with the functional tests is called? [02:43] wallyworld, IIRC sinzui sent round a mail saying where it was and a bit about how to write new ones, but I can't find it [02:44] hmmm. i can't recall, but i can look [02:45] I thought it was under ~juju-qa, but I don't see the branch name I'm looking for [02:45] ci-cd2 something something [02:45] ci-cd-scripts2 -- that might just be the support scripts tho [02:45] axw, yeah, all I could remember was there was a "2" in the name [02:46] lp:juju-ci-tools [02:46] i think [02:47] yeah, that matches what I have on disk for ci-cd-scripts2 [02:47] must've been renamed [02:51] axw, am I being dumb? I don;t see any actual *tests* in there [02:52] fwereade: I think they're just mixed together with support code. I'll follow through from jenkins and find one [02:54] fwereade: the aws-deploy-trusty-amd64 job just runs this: http://paste.ubuntu.com/7833744/ [02:54] fwereade: backup/restore runs test_recovery.py [02:55] with some args [02:55] axw, yeah, I just found that one, but I feel it's likely that that's not the only one... [02:56] fwereade: it's not. are you looking for something in particular, or you just want to know what our set of functional tests is? [02:58] axw, yeah, I just want to tell ericsnow to write big new tests as FTs directly, and to do it in instead of juju-core [02:59] I see. probably best off getting sinzui's advice then [03:00] or maybe abentley [03:00] just in case anyone was confused, i really hate JujuConnSuite [03:03] davecheney, I too have a deep and abiding loathing for that thing [03:04] fwereade: i want to cleeve it in two [03:05] JujuClientConnSuite and JujuServerConnSuite [03:05] then at least for the moment, recombine them into some horrific lovecroftian monster as JujuConnSuite [03:06] menn0: % df -h /tmp [03:06] Filesystem Size Used Avail Use% Mounted on [03:06] tmpfs 3.9G 1016M 2.9G 26% /tmp [03:06] this is what a day of running juju tests looks like [03:09] I'd rather we just didn't use full end-to-end testing for our unit tests [03:09] why is shit getting left behind in tmp now? I don't think it used to? [03:11] axw: always leaks like a mofo [03:11] wallyworld: I can't reproduce the ec2 failures :/ [03:11] especially if your fixtures panic [03:11] axw: note, i wasn't complaining [03:11] i'm used to it [03:12] axw: yeah, i suspect it's on the ec2 side [03:12] davecheney: hmmok. I'm complaining, because I actually ran out of tmpfs the other day ;) [03:15] wallyworld: according to the AWS docs, it just means the server is overloaded. I guess it's more likely to happen in a US region during US-friendly hours [03:15] AWS status page has nothing much to say [03:15] yep. can you comment on the bug, so that curtis knows we've looked at it? [03:16] sure [03:20] axw: so, state of session copying branch. i have got a passing set of unit tests (with occasional replicaset failure). but bootstrapping a real env fails - 2014-07-22 03:18:28 ERROR juju.cmd supercommand.go:323 failed to initialize state: cannot create state servers document: not authorized for insert on juju.txns [03:21] it will be something simple, so i should be able to propose something soon [03:21] hmm ok [03:21] not sure just right now exactly what the issue is though [03:21] is this related to the thin michael emailed about? and that jam suggested we might be able to drop? (the mongo password dance) [03:22] thing* [03:22] could be, but I think that has been changed in this branch, i need to go look into it [03:22] ok [03:22] i'll get you to review later, but here's the current diff https://github.com/wallyworld/juju/compare/copy-session [03:50] fwereade: can you explain the rational for this signature and comment ? [03:50] func APIInfo(env Environ) (*api.Info, error) { [03:50] bugger [03:50] // APIInfo returns an api.Info for the environment. The result is populated [03:50] // with addresses and CA certificate, but no tag or password. [03:51] thumper: https://github.com/juju/juju/pull/346 question in user_test.go:106 [04:00] thumper, http://paste.ubuntu.com/7833982/ [04:36] wallyworld: #1344857 <- this was fixed for 1.20, but not in the 1.18 branch [04:36] <_mup_> Bug #1344857: Crash deploying landscape-dense on MAAS

[04:36] fixed some time during 1.19 anyway [04:36] added a comment [04:37] about to propose a fix for the machine-agent suciding bug [05:17] axw: so, using session.Copy() results in all sorts of permission errors, whereas session.Clone() doesn't [05:18] Clone doesn't create a new socket [05:18] the different at the mgo level is that Copy() makes a Refresh() cal lon the session which releases the socket [05:19] thumper, https://github.com/juju/juju/pull/358/files [05:19] yes, so now the question is - why does acuiring a new socket cause mongo to reject collection queries etc as unauthorised [05:20] wallyworld: I can only guess that it has to do with Login is being called after the session is copied [05:20] so other sessions don't inherit the credentials [05:21] could be [05:24] yeah, looks like i need to rearrange some code [05:25] fwereade: https://github.com/juju/juju/pull/359 [05:25] a semi seroius attempt to reduce the horror [05:25] for comment, not review [05:30] hmmm, maybe not. Login() is called first [06:11] wallyworld: getting anywhere? [06:12] axw: sorta. state.Open() is first called with no credentials, and that fucks up everything from that point onwards [06:12] because there are no credentials, db.Login() is never called [06:13] so credentials are never set on the session [06:13] I see [06:13] but it tries to use the session via session.Copy() [06:13] using the session directly (which also has no creds) works [06:13] huh [06:14] so i thin we must be calling Open() twice [06:14] once without creds and once with [06:14] well, that's my theory [06:17] i think it's all tied up in how we initially create the admin user [06:21] ah, it's in agent/bootstrap [06:21] we create an initial state as part of the bootstrap process, but without user or password [06:21] * wallyworld bbiab, raining, goota get kid from train startion [06:21] right, cos it's the first connection to mongo and there are no users yet [06:21] yeah [06:22] so have to special case that somehow === eagles05- is now known as eagles0513875 [07:13] morning === uru_ is now known as urulama [10:11] good morning everyone, please remember dimitern and I will be your on call reviewers today :) [10:17] mornin' [10:17] perrito666: morning [10:18] perrito666: dimiterm isn’t available, diving holidays [10:19] TheMue: then its only me :p [10:22] perrito666: but I can support you, currently only fighting a bit with my machine after upgrading [10:40] wallyworld: I've got some things to do after dinner, so may be late for / miss the standup [10:40] sure, np [10:40] thanks for doc, haven't read it yet [10:41] i think i'm going to revert michael's changes to txn runner so we can control when session is closed [10:41] mk [10:41] i should say Copy()ied [10:42] cause now, it copies inside txn runner even when it's not appropriate to do so [10:42] the caller (state) should be in control of when a session is copied [10:42] as it knows if the credentials have been set [10:43] it's a bit messy [11:17] TheMue: i realized I just went through our standup time, I had an interview I was conducting. Want to touch base in about 5 min? [12:22] jam: ah, hey, just back from lunch. after you didn’t came I thought that watching the games has been too long. :D [12:24] morning all [12:24] natefinch: morning [12:26] natefinch: morning [12:26] * perrito666 uses a rather inefficient method to find out code to be reviewed [12:27] perrito666: looking through the entrails and chicken bones for URL fragments? [12:27] perrito666: which one? [12:28] TheMue: the one jam1 just mentioned [12:28] TheMue: I open all the repos of gh/juju/ and then click on the ones that actually have pull requests [12:29] perrito666: yeah, I’m looking at the PRs and use also the number of comments as a hint if nobody has looked at a PR so far [12:29] * perrito666 senses a script in the near future [12:30] btw, what is dave cheney's nicnkane on irc? [12:31] davecheney [12:31] ;) [12:37] * TheMue is happy enough that his local provider is working again. :) somehow it yesterday didn’t wanted to start the API server :( [12:37] can anyone shed some light here? https://github.com/juju/utils/pull/7 I think axw and I are right and I am inclined to merge this [12:38] perrito666: will take a look [12:38] tx [12:45] perrito666: hmmm, I do understand dave, it hurts a bit to see those two Close so near to each other. the defer relies on the fact that Close only may return an error but doesn’t hurt more (eg. with a panic in case of an already closed file) [12:46] perrito666: just looking for a way check if the file is not yet closed, so defer would use a func() { if f.IsOpen() { … } } [12:46] perrito666: sadly it doesn’t exist [12:47] I guess that could be split into a couple of functions but I believe it is a bit overkill [12:47] perrito666: so yeah, we have to act this way, otherwise ReplaceFile would have to be changed to use a os.File instead of prep and path [12:47] TheMue: I think it's a lot clearer to use two closes rather than defer and close. Defer and close looks like a bug. two closes looks like we're choosing not to use defer. With a comment as to why we have to close before replacing, it'll be totally clear and ok. [12:49] natefinch: yep, the comment would help to not struggle about it later [12:50] TheMue: yeah. I can just totally see someone coming by and deleting the f.Close because it's extraneous due to the defer (or convert both closes back to a defer in the case of the two close form) [12:51] natefinch: hehe, death by refactoring [12:52] that's half the reason I comment stuff... so the guy coming into the code 6 months from now won't go "wtf is this? man, what an idiot, I'll just fix it...." and then break stuff (P.S. that guy in 6 months is often oneself ;) [12:53] heh, that's a funny pr [12:53] mgz: it has an amazing review/changes ratio [12:53] nate's solution seems the best, f.Close twice after f.Write, on the error and non error branches [12:54] or put Write and the error check on seperate lines so you can Close between them (and comment, of course) [13:15] natefinch: I just noticed in the log after the workaround thumper asked us to try this: 2014-07-22 13:12:37 ERROR juju.worker runner.go:218 exited "state": failed to add "machine-0" to admin database: cannot set admin password: system.users entry must not have both 'roles' and 'readOnly' fields [13:15] after that, the db service stopped. I'm thinking if fixing this could maybe fix the ha [13:16] hackedbellini: hmm weird [13:18] do you or anyone here knows how to workaround that? [13:19] jam1: ping [13:20] TheMue: pong [13:21] jam1: the LXC card tells that an lxc instance has no IPv6 address. who’s the source of this info? [13:21] hackedbellini: looking [13:21] TheMue: when I've tried the local provider, and then run "sudo lxc-ls —fancy" I see it list an IPv4 address but "—" for ipv6, has this changed? [13:21] jam1: when I’m starting LXC manually as well as via juju (using the local provider) it has an IPv6 address [13:23] jam1: hmm, interesting, using lxc-ls it doesn’t show the IPv6, yes [13:23] hackedbellini: it seems like the problem is that we're trying to modify the user, but that's not really how you're supposed to change passwords on users anymore [13:24] jam1: but when visit an instance with juju ssh 1 and do a ifconfig -a I do see it, bound to eth0 with the same address lxc-ls show [13:24] shows [13:25] natefinch: that error was new after setting the "upgradedToVersion" = 1.18.4. Do you think that this error is a side effect that happened after the agent was trying to "fix" the ha migration? [13:25] niemeyer: ^^ It looks like juju is using mgo.Database.UpsertUser to change passwords, but mongo really wants us to use changeUserPassword: http://docs.mongodb.org/v2.4/tutorial/change-user-password/ [13:26] jam1: ah, the IPv4 can be pinged, the IPv6 not, interesting [13:27] hackedbellini: I think you're hitting a weird upgrade path where you're half upgraded, because you're really on 1.19 and not 1.18, so some of the upgrade code is failing because it expects the user not to exist [13:29] natefinch: hrm, so this is actually good. It's trying to migrate from 1.18 to 1.20, that's what we wanted. Any way to "skip" those already migrated code? [13:30] TheMue: so I think the ubuntu that comes up in the LXC is auto-assigning something, but it isn't being made routable by the LXC outer machinery. [13:32] jam1: looks like, the standard address is link-local [13:38] good morning all [13:39] katco: heya [13:39] hey katco [13:39] TheMue: mgz: hi :) [13:42] natefinch: What's the actual error, and what is the version of mgo and of MongoDB [13:46] natefinch: FWIW, db.changeUserPassword is just a wrapper, which just updates the user using one method or the other depending on which version of MongoDB you're using [13:46] natefinch: In theory, the latest version of mgo does exactly the same.. [13:47] natefinch: Unless there's a bug, which I'd be happy to know about [13:49] niemeyer: we're getting "system.users entry must not have both 'roles' and 'readOnly' fields" [13:50] natefinch: What is the version of mgo and MongoDB you are using? [13:51] natefinch: This sounds like a really old behavior.. even an older mgo should be able to cope with that, unless you are actually trying to modify the database yourself, in which case you are of course on your own [13:52] hackedbellini: I presume you have mongodb 2.4.6? [13:52] niemeyer: we're just using UpsertUser: https://github.com/juju/juju/blob/1.20/mongo/admin.go#L114 [13:53] natefinch: Okay, so that should be working fine [13:53] niemeyer: mgo is labix.org/v2/mgo 20140331185009-fhnh3xzfdpicup0j [13:53] natefinch: Testing.. [13:54] niemeyer: the question is what would happen if you ran that code twice? I have a feeling that's what happening. hackedbellini's state server is in a weird state - he got upgraded to 1.19 from 1.18, and now we're trying to get him to 1.20... my guess is that the upseruser code got called from 1.18-> 1.19 and now is getting called again from 1.19->1.20 [13:56] natefinch: Ah, hmm.. [13:56] natefinch: If you try to upgrade a user from a password-less state to a password-rich one, yeah, you might have issues [13:56] natefinch: Erm, sorry [13:56] natefinch: If you try to upgrade a user from a role-less state to a role-rich one, yeah, you might have issues [13:57] natefinch: There's no "readOnly" field in there [13:57] natefinch: So I assume that field is in the database already, from an ancient run [13:57] natefinch: So the error is correctly saying you cannot do that [13:58] niemeyer: yeah, that's what I was thinking. I wonder if we should just override readonly [13:59] natefinch: This was unfortunately quite fiddled with during MongoDB 2.2 => 2.4 => 2.6 [13:59] natefinch: I did my best to sanitize the upgrade path for driver users, but the server did change significantly and certain cases are just not doable [14:00] natefinch: You can try dropping readOnly, yes, but I suggest testing it both in 2.4 and 2.6 [14:00] natefinch: The manual dropping code will not work on 2.6, as user changes are now done via commands rather than directly fiddling with the db [14:01] niemeyer: yeah, we're working on 2.6 compatibility.... but so much changed, it's quite a process. [14:01] natefinch: So probably "drop on 2.4" + "check for that one error on 2.6 and ignore" [14:01] natefinch: Yeah, user managed, specifically, did change both on 2.4 and on 2.6 [14:02] natefinch: I'm hopeful the fiddling is done now. [14:03] wwitzel3: stdup? [14:03] niemeyer: thanks for the help. I'll make that fix, in case anyone else hits this (this is a pretty bizarre case, but shows it's not impossible) [14:04] natefinch: No problem [14:05] perrito666, wwitzel3: brt, one minute [14:20] natefinch: sorry I was helping a workmate here. The mongodb version is 2.4 here. [14:20] I saw that you and niemeyer were discussing some things regarding my problem. Is there anything you want me to try? My installation is totally broken, so I have nothing to loose (well, I cannot loose in any case the data on the lxc machines, since they are on production, but I don't think that will happen) [14:27] hackedbellini: we could have you twiddle the DB manually, but I think I'd rather get the fix into production and have you retry the update after the fix [14:36] natefinch: hrm, perfect! When do you think that update will be available? I will probably have to download the tools by hand, right? Since I can't do an "upgrade-juju" [15:36] what is the normal approach to testing internal helper functions? [15:36] should we export the internal functions so that the tests can see and test them directly, or do we rely on the helper functions being implicitly tested by the public functions being tested? [15:37] perrito666, mgz, natefinch, et. al. ^^^ [15:40] jcw4: in that case I usually add a test in the package [15:40] perrito666: i.e. in the actual package rather than in package_test [15:40] yup [15:41] jcw4: but dont take my word as law I am far from elder here [15:41] :) [15:41] I've heard strong opinions against that, but possibly there might be exceptions for internal helper methods [15:42] jcw4: I pretty much always prefer the export_test.go method [15:42] mgz: @more [15:42] @more? [15:42] jcw4: Error: "more?" is not a valid command. [15:43] lol [15:43] ah, [15:43] lol [15:43] mgz: meh, you could very well support basic irc bot commands [15:43] for any non-trivial internal function, having dedicated unit tests makes sense, rather than just testing at pubic interfaces (which some prefer) [15:44] so, just have a SomeInternalFunction = someInternalFunction in export_test.go in that package [15:45] and test at that level [15:48] mgz +1 [15:48] perrito666, mgz I'll add some tests and then ask for a review again [15:50] btw, there are a bunch of prs from 26 days ago about cloud sigma that no one commented on, is there a reason for that? [15:50] perrito666: congratulations, you get to review them I think [15:50] hehe [15:51] mgz: I am on it, just wondering if there was a deeper reason for them to be ignored for almost a month [15:53] perrito666: not that I'm aware of, apart from some obvious reviewers being enveloped with other things [16:04] mgz: hey, i'm unsure of where to put this test for including the simple-streams URL in the container start. my options are juju/juju/container/kvm/kvm_test.go and live_test.go. live_test.go looks like it has some container-ish tests in it, but the change will be in kvm.go... thoughts? [16:05] katco: I'd try to put in kvm_test.go even if it means adding a new suite there [16:06] mgz: k that's what i was thinking initially; thank you :) [16:14] I just burned frozen burgers... that must be some sort of special skill [16:14] perrito666: I thought you were the chef in the house... [16:15] mgz: I am, I just got distracted by a code review [16:15] riveting code review [16:15] scorching code review... [16:17] mgz: well this burned food will definitely affect the outcome of the review [16:17] haha [16:18] "this is the worst object instnatiation i've ever seen. the formatting is crap, and i'm hungry. dnflgtm" [16:18] lol [16:22] jam, jam1: ping [16:28] cmars: ping [16:35] i need a second opinion on a design decision; anyone available to PM for a few minutes? [16:38] katco: bug perrito666, he's in a good mood and not otherwise occupied [16:38] rofl [16:38] perrito666: if that's true, got a sec? or are you munching on some burnt lunch? ;) [16:39] katco: more seriously, you can bug me if you like :) [16:39] mgz: that would probably be best since we're on the same team :) [16:53] jcw4: for what it's worth, I think export_test.go is an anti-pattern. I think it is doubly so when you're doing it so you can test an implementation detail like an unexported method . Just make a new testing file that is in the same package as the test, and write your unit test there. There's a reason both test forms exist. [16:59] mgz: mm I see you have managerial talent [17:00] katco: I am in a good mood, excepting for that incident with the chickenburger, so fire away [17:00] perrito666: mgz helped me out, but thank you! [17:02] perrito666: I can be useful, as well as wind people up about their burnt burgers :) [17:24] natefinch: thanks [17:25] jcw4: as others said, not everyone agrees with me.... but I don't think anyone will stop you from writing more tests :) [17:25] haha [17:26] I have had in-package tests merged so I guess no one has very strong objections [17:26] I'll clear it with mgz, and decide between a separate .go file and the export_test.go file, but either way I have to make perrito666 happy [17:26] ;) [17:27] jcw4: well, you will not make me happy per se (not after my burguers charred) but you might get a lgtm from me if you add tests :p [17:28] lol [17:28] from my perspective that's the same thing [17:28] ;) [17:31] I need someone with managerial skills for a quick question [17:32] perrito666: you can't expense the heroin, I told you that [17:32] natefinch: maan, whyyy? [17:32] perrito666: whazzup? [17:33] natefinch: I pmd you [17:53] perrito666: jcw4: i am thinking about the same thing. i think the idiomatic thing to do is to keep the tests in the same package. they will only get included in the test binary, not the production binary. [17:53] perrito666: jcw4: and it avoids the export dance for tests [17:54] katco: okay, I haven't heard from mgz and it sounds like a bit of a quorum so I'll go with in-package tests [17:54] jcw4: mind you i am brand new, so my opinion probably doesn't count for much :) [17:55] katco: haha - well change is easy. But, when I see fairly divergent opinions regularly on the project I think it just means a clear standard has yet to emerge [17:56] well then i'll throw my hat into the "keep in the package" ring. if it's good enough for the standard lib, it's good enough for me :) [17:56] :) [18:07] FWIW, last I saw, niemeyer favored the *_test package approach, which somewhat explains our use of it :) [18:08] see https://groups.google.com/d/msg/Golang-nuts/dkk0X1tIs6k/nO3CKFqbIxYJ [18:08] +1 [18:10] sounds to me like: Public API in package foo_test and Private in _test.go file of foo package but I did not read the whole link from ericsnow :) [18:11] testing things as they are intended to be used [18:11] Yep [18:11] In many cases, it's also easy to export the things that are internal so that they can be touched by tests, using the export_test.go trick in use in many packages [18:12] Also like that extra mile.. encourages people to be more honest about testing what is meant to be tested, rather than implementation details [18:16] hmm; the quorum is crumbling.. since I report to mgz and niemeyer is an elder in the community I'm going to flip flop and go with export_test.go :) [18:17] jcw4: It's hard to give reasonable advice without knowing what the case is, though.. what are you testing? [18:17] niemeyer: helper functions in the actions and actionresults watchers [18:17] jcw4: URL to the code? [18:18] niemeyer: https://github.com/juju/juju/pull/351 ... specifically : [18:19] https://github.com/juju/juju/pull/351/files#diff-5a822a48b96dd79a90eda5ba852495c4R1673 [18:19] niemeyer: I'm actually about to refactor them down to one watcher with a parameter for which collection to watch... [18:21] jcw4: I'd be on the fence on that one.. it's all internal, and it's a relevant abstraction that deserves testing [18:22] jcw4: It's previously existent code, so I'd probably just go with what is already in place unless I had an actual reason to change it [18:22] jcw4: (other than purism) [18:22] niemeyer: meaning the refactor to one watcher? [18:22] or the helper functions [18:23] jcw4: No, meaning the subject of our conversation [18:23] :D [18:23] okay [18:24] niemeyer: I'll see what in-place testing there is for helper functions and if there is none then I'll export the couple helper functions we want to test... [18:33] ericsnow: niemeyer: ty for the context :) === gsamfira1 is now known as gsamfira [20:58] thumper: got a minute to talk about jujud logging? [20:59] natefinch: sure, a few [21:00] thumper: just as easy on irc..... basically, there's the log rotation bug that has come up again. I wanted to use a Go package for rolling Jujud logs so it'll work when we support windows.... but the relationship between the commands and logging and stuff is kinda twisty [21:01] natefinch: oh... kay.. [21:01] natefinch: what needs to be done is this: [21:01] 1) at the startup of jujud, configure the logging to use the special writers you have [21:01] 2) change the upstart scripts so it writes out to a file, not to stdout/stderr [21:01] or at least, logging goes to the file [21:02] I don't think we write anything else out [21:02] yeah….. [21:02] just that... [21:02] changing the upstart scripts are the biggest thing [21:02] thumper: so, we have a few different commands, bootstrap, machine agent, unit agent, juju-run [21:03] thumper: to get the right directory in which to configure loggo's output on startup, we need the agentConf, which everything except juju-run has access to right now. [21:04] don't worry about juju-run [21:04] it sends stdout, stderr back to the client [21:04] ok, that was sort of my question [21:04] and shouldn't log [21:04] right, that make sense [21:05] ok... so I think the only thing we have to do is change cloud-init to modify the upstart script, but I guess we'll need an upgrade step to modify the upstart script of existing installations [21:06] so... three, three things we have to do: configure loggo for the commands, change cloud-init, and update the existing upstart scripts of running machines [21:08]