[01:07] woot! the logging-to-mongodb feature branch has landed [01:08] menn0: wow! congrats :D well done! [01:08] anastasiamac: cheers [01:08] I just checked the size of the diff to master: 3,500 additions and 852 deletions [01:08] menn0: would love to know of ur experiences in terms of wirtting ci tests for it as well as user-facing documentation [01:09] menn0: when did u create the branch? (for how long have u had it running?) [01:09] anastasiamac: there is no user facing documentation, b/c from the user's perspective nothing changes [01:10] anastasiamac: it's just a necessary change for JES ... and it's a little less fragile than all-machines.log [01:11] anastasiamac: not sure how old the branch is... around mid April [01:11] except we can't use a text editor when mongo dies :-( [01:11] menn0: so there r no changes to configuration [01:11] me? [01:11] wallyworld: you still have a text log file of all received logs per state server [01:12] which we need to accumulate by hand and which are not interleaved [01:12] wallyworld: that's the fallback [01:12] yeah, i know, i'm just grumpy [01:12] wallyworld: yes, if there are multiple state servers [01:12] no i mean all machines log also contained logs from nodes [01:12] all interleaved [01:13] so you could easily see sequencing [01:13] wallyworld: yeah I understand [01:13] i often ssh into a state server and grep that file [01:13] far easier than debug log [01:13] wallyworld: well the next thing is to expand debuglog's capabilities then [01:13] yeah [01:14] sorry for grumping, will just make my life harder now [01:14] i understand the reasons for it [01:14] wallyworld: for example, selecting time ranges is largely implemented on the server side but needs client side support [01:14] it's the lack of exploring which is the main thing [01:14] easier to just flitter around in a text file [01:16] menn0: weren't u at one stage considering to make log output destination (file, db, etc) configurable? [01:17] anastasiamac: no I don't belive so. it's hard to effectively handle logs for multiple environments in a single file. [01:18] wallyworld, anastasiamac: with the way it's the feature is structured it wouldn't be too hard to generate a all-machines.log or even separate log files per env from the DB. [01:19] yay [01:19] wallyworld, anastasiamac: with the bonus that it doesn't involve rsyslogd [01:19] even better :-D [01:19] we'd just need a worker which tails the DB like the debuglog API does and generates the file [01:20] all the pieces are decomposed in such a way that this wouldn't be hard at all [01:21] friday labs :-) [01:22] menn0: this is great! and the feature (as well as its design) would b an awesome demo for team meeting - again tyvm for the feature :) [01:46] anastasiamac: yep good idea [01:46] * menn0 is having lunch so sorry for the delay [02:21] waigani: hey, did you see the maas output on that bug? looks like maas is doing the right thing? [02:22] wallyworld: ah really? hmph. well there goes my theory. At least we can test with that as mock output - try to reproduce it in a test. [02:23] waigani: well, i think it is correct, only took a quick look [02:23] but we have the output [02:23] wallyworld: I'll try to take a look today, but I need to finish off this branch - I'm on leave for the next 4 days [02:24] great that we've got the output though, should be helpful [02:32] waigani: ok, see how you go, let me know where you get to [02:32] wallyworld: will do, I'm not far off... [04:09] wallyworld: looks like gomaasapi wan't reading the substatus. Here's a PR to fix that: https://code.launchpad.net/~waigani/gomaasapi/substatus/+merge/264371 [04:09] waigani: ty, looking [04:09] wallyworld: I've also added that to the bug as a comment. [04:10] waigani: so that's a fix for the test service in gomaasapi, we still need to fix juju as well right? [04:11] wallyworld: once that gets signed off, it should just be a matter of bumping the dependancies.tsv [04:11] wallyworld: and probably adding a test [04:11] waigani: how? the pr above doesn't fix anything [04:11] it fixes a test server [04:12] wallyworld: ugh, facepalm [04:12] wallyworld: let me go back [04:12] ok [04:13] wallyworld: right, yeah sorry so the juju side is still to come [04:13] sure [04:14] but it looks like that's the problem, as you can see from that test [04:14] wallyworld: the one thing that makes me nervous is that we are flattening two dimensions into one [04:14] let me look at the maas output [04:15] wallyworld: as juju status doesn't have any concept of a 'substatus' so, we just need to be careful how we decide which status/substatus gets reported [04:19] waigani: so the maas "deployment_status" api call returns a string doesn't it? [04:19] "Failed Deployment" or "Deployed" etc [04:19] wallyworld: yeah [04:19] so we don't need to worry about interpretting status vs subststus [04:20] is it only older maas deployemnts without the new api call? [04:20] wallyworld: let me look and I'll get back to you [04:21] ok [04:21] wallyworld: just seeing how we dial up that status from the juju side [04:21] juju calls deployment_status [04:22] well, it does while it waits for the node to come up [04:31] wallyworld: add this to tip of 1.24: http://pastebin.ubuntu.com/11853823/ [04:32] wallyworld: it passes [04:32] looking [04:32] wallyworld: and yeah we call deployment_status in maas/environ.go deploymentStatusCall [04:33] wallyworld: so it's reporting the correct error [04:34] waigani: i'm not sure that's all correct - that test could pass if the status stays "pending" [04:34] i don't see how we're testing the maas status interpretation [04:35] and adding a test against a modified test server in gomaas doesn't really prove anything [04:36] wallyworld: right, fair point. [04:36] wallyworld: how about I checkout 1.24.1 (same as in bug), revert changes to gomaasapi and work on improving this test? [04:37] try and reproduce a test failure (write a new failing test). then fix juju so the test passes [04:37] TDD and all that [04:37] target the test to the specific issue [04:37] wallyworld: actually I did run that test on the unmodifed server - and if you comment out the "substatus" line, it's fails - as expected [04:37] other more general bootstrap tests could also later need changing, but there should be a targetted, specific test done first [04:38] yes, but that's because the test is relying on the behaviour of hte test server [04:38] and the test server reports "Deployed" - status 6 [04:38] in the absense of sub status 11 [06:04] wallyworld: I can't get it to fail, I've written a summary on the bug. I've asked to look at the logs. [06:05] did you test with real maas? [06:05] or vmaas [06:05] wallyworld: I was just about to say, that's the next step [06:06] it won't fail if you just test with the gomaas test server [06:06] unless the test server mimics the maas output [06:06] which it doesn't appear to [06:06] wallyworld: yeah, that's what I did - as explained in the bug [06:07] ok, i'll read the bug :-) [06:09] waigani: thanks for looking into it, enjoy the time off. i'll see what we can make of it [06:11] wallyworld: thanks. I'm keen to know the cause. [06:11] i'll update the bug [06:11] when we find it [06:11] ah I was just about to [06:12] wallyworld: updated [06:13] waigani: it could be that an old api call to get status is being made, and hence sub status is ignored - that would be my guess [06:13] anyways, we'll see === liam_ is now known as Guest18768 [09:01] fwereade: interested in a quick chat ;) we're alone today [09:31] fwereade: hi, please dont forget my branch if you have the chance [11:53] perrito666, sorry, the diff looks mangled? would you update and try again please? [12:33] fwereade: sure [12:35] mm, says rbt it cannot reach reviewboard, odd [13:04] fwereade: sorry rbt is playing dumb with me [13:38] voidspace: heya Michael, everything alright with your car? [14:02] katco: perrito666 : there is a new reression in master, bug 1473461 Maybe we want to backout a branch becaue the fix is to write a darwin-specific ./cmd/jujud/util/password/password_darwin.go [14:02] Bug #1473461: OSX/darwin builds fail: undefined: password.EnsureJujudPassword

[14:03] Bug #1473450 opened: upgrade-juju from 1.18 to 1.20.4 leaves some agents down [14:03] Bug #1473461 opened: OSX/darwin builds fail: undefined: password.EnsureJujudPassword

=== kadams54 is now known as kadams54-away [14:10] TheMue: was my review of http://reviews.vapour.ws/r/2129/ helpful? [14:10] ericsnow: very, thanks. I'm working on it. [14:10] TheMue: cool :) [14:11] bogdanteleaga: that password thing is yours :) [14:11] TheMue: I'll try and give you a quick turnaround as soon as you have any comments or updates to the patch [14:12] ericsnow: there has been a longer discussion about the EntityWatcher before. the first Addresser approach used the IP address values. but then Dimiter said it would make sense to use common.LifeGetter and common.Remover. [14:12] Bug #1473466 opened: When using openstack as provider lxc containers get a hardcoded ip

[14:12] ericsnow: so we needed tags for ip addresses, an earlier chnage. [14:12] ericsnow: and this code is mostly based on http://paste.ubuntu.com/11803914/ [14:13] TheMue: ah [14:13] ericsnow: should have written more into the description *lol* [14:13] TheMue: it just struck me as odd that the EntityWatcher was part of this patch :) [14:14] TheMue: yeah, how terrible of you [14:14] ericsnow: it rushed in as a side-effect. would have been worth an extra change, yes [14:14] hehe [14:16] TheMue: not really a blocker, but putting multiple effectively distinct changes in a single patch can be a problem every long once in a while (in this case not a big deal) [14:18] ericsnow: what? you need more than one commit to implement ? :D [14:19] TheMue: well, not me personally ;) just this guy I know (okay it's me) [14:19] :,) [14:42] Bug #1473470 opened: Windows cannot ensurePassword

[14:54] hello akhavr welcome! [14:54] alexisb: :) [14:56] ashipika: around? [14:57] perrito666: here [14:58] just something I found and might bite you in the future [14:58] perrito666: do tell, please [14:58] ashipika: priv === kadams54 is now known as kadams54-away [17:20] sinzui: around? [17:22] perrito666: I am [17:22] sinzui: I am trying to use boot_context in my CI test [17:23] i feel a bit of a lack of clarity regarding what should the arguments be [17:26] perrito666 in deploy_stack.py deploy_job() -> deploy_job_parse_args(), _deploy_job() -> boot_context() [17:27] perrito666: the parse args will have descriptions [17:27] ah, excelent, thank you [17:27] perrito666: I think we want to add a ricj docstring to boot_context() to encourage it's use [17:28] perrito666: I will take a stab at the docstring in a few minutes, and pass it for review for you and maybe abentley [17:54] Bug #1473517 opened: juju environment not usable after the upgrade [18:37] sinzui: back, sorry, 2 things, 1) what is bootstrap_host supposed to be and 2) job name can be set to something arbitrary or do I need to add it as an arg? [18:38] job_name is arbitrary yes, but it is alos unique so that the script and base env can be run in parallel [18:39] and bootstrap_host? [18:39] perrito666: bootstrap_host is not required. it is a placement directive for bootstraping manual or maas [18:40] None will suffice or you are expecting it to be a given type? [18:40] perrito666: yep [18:44] ok this function is too long [18:49] sinzui: ok, almost there: agent_url and agent_stream? [18:51] perrito666: agent_stream == agent-stream in config. None means don't override [18:51] perrito666: agent_url == agent-metadata-url in config. None means don't override [18:52] perrito666: We use these often and will be required to run revision tests in parallel when we need concurent streams [18:52] well we do, which is why the configs force the testing streams [18:53] sinzui: so you are saying I should make these args [18:55] perrito666: all of those things need to be args becauee we may need to run the test with manual and we certainly will be running with streams created for the test [18:56] sinzui: I find then odd that those are not part of add_basic_testing_arguments [18:57] sinzui: Do you know if anyone has an RPM to install juju client? [18:57] perrito666: the only arg from that may be dropped from (job_name, client, bootstrap_host, machines, series, agent_url, agent_stream, log_dir, keep_env, upload_tools) is upload_tools because we discovered this week that we cannot fallback to upload-tools with the new os and arch requirements [18:58] mbruzek: I have not seen one. mbruzek Since client relies on ubuntu-ness I doubt anyone succeeded [18:58] sinzui: ack [18:59] mbruzek: the centos client will work for centos https://launchpad.net/juju-core/+milestone/1.24.2 [18:59] mbruzek: only centos7 actually. I thnk an error is quickly raise of the host os/series is not recognised [19:00] sinzui: Marco and I just tried to alien the debian packages, it didn't work... yet [19:01] mbruzek: I am sure the deps wont work becaue mongo is not packaged to meet Juju's needs [19:01] OK Thanks sinzui [19:15] sinzui or jog: Could you please review https://code.launchpad.net/~abentley/juju-ci-tools/s3-download/+merge/264450 ? [19:15] abentley: looking [19:16] sinzui: thanks. [19:17] sinzui, perrito666: I think that --upload-tools is nice to have for devs who are testing their self-built jujus. [19:17] abentley: I can and maybe should install s3cmd on all slaves [19:17] abentley: My one mac has it [19:17] sinzui: Oh. Well, if we do that, we can rip out s3 support for the workspace runner. [19:18] abentley: then I wont because I like what you have written [19:19] sinzui: I do like the idea of isolating the resource retrival/publication from the testing step. [19:20] yeah, this is awkwardly coupled. Isn't this because we haven't updated the build job to also upload to s3 yet? [19:21] sinzui: It's because we haven't done download support for workspace-runner. [19:21] sinzui: We can scp files, which is useful, but the remote client can't download files from s3. [19:32] abentley: This command now works on the osx-slave [19:32] s3cmd -c cloud-city/juju-qa.s3cfg ls s3://juju-qa-data/ [19:33] sinzui: Okay, I can switch it over to use s3cmd. [19:34] abentley: I can add s3cmd to windows, but I don't want to give it credentials. I think I put myself in a corner [19:35] sinzui: If the plan is to ultimately have our windows jobs uploading everything directly to s3, that would be a problem. [19:36] sinzui: Obviously, we can have separate win credentials. [19:43] abentley: The win-client-deploy job need the installer built by build-win-client.The current rule is the ci job procurs the installer under test and delivers it to the win machine. [19:46] sinzui: Right. Basically the same pattern I was following with run-osx-client. [19:46] yes. In egnlish, test this using with